docs(sdlc): finalize ISO 29110 evidence package

2026-08-26 12:35:57 +07:00
parent c7821b9d2d
commit 45b2415beb
53 changed files with 195 additions and 27 deletions
@@ -25,6 +25,37 @@ Sections 6, 8.5, 12.2 and 16 describe outcomes as at 17/08/26; the remaining sec

 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.

+### 1.1 Standards basis and applicability
+
+BRN WMS applies the ISO/IEC 29110 software engineering Generic Basic Profile for one non-safety-critical software product developed by one project team under a customer project agreement. The standards basis for this project is:
+
+- **ISO/IEC 29110-4-1:2018** — Software engineering profile specifications for the Generic profile group, including the Basic profile.
+- **ISO/IEC 29110-5-1-2:2025** — Software engineering management and engineering guidelines for the Generic Basic profile.
+
+| Applicability item | BRN WMS application |
+|---|---|
+| Profile group | Generic profile group |
+| Profile | Basic profile |
+| Engineering discipline | Software engineering |
+| Project organization | One project team with assigned management, analysis, development, testing, document-control, and customer-approval roles |
+| Product scope | One browser-based warehouse management software product and its supporting deployment/service components |
+| Agreement | Customer project agreement controlled through the Statement of Work and Customer Requirements |
+| Safety criticality | Non-safety-critical software |
+| Management process | Project Management |
+| Engineering process | Software Implementation |
+| Lifecycle | Incremental/evolutionary implementation with controlled requirements, configuration baselines, verification, validation, and acceptance |
+| Tailoring principle | Work-product structure and detail are scaled to BRN WMS size and complexity while retaining controlled content, responsibility, review, and traceability |
+
+### 1.2 Work-product tailoring
+
+- Project Plan content is controlled across the Work Schedule, this Software Project Plan, and Customer Requirements.
+- The Software work product is the Git-controlled application baseline; work product 17 is its controlled identification and repository pointer record.
+- The Traceability Record (work product 13) is the master requirements matrix. The additional Traceability Record Table is a summary/pointer and does not create a second competing baseline.
+- Test Cases and Test Procedures defines the tests and records their execution status; the separate Test Report consolidates the results and disclosed evidence limitations.
+- The Project Charter Report, Stakeholder Register, List of Evidence, Traceability Record Table, and Training Report supplement the Basic-profile work products without replacing them.
+- Markdown files under `sdlc/` are the controlled editable document sources. PDFs under `sdlc-delivery/` are generated delivery/printing outputs and are not edited independently.
+- No Project Management or Software Implementation process is declared excluded. Content granularity is scaled where documented, including requirement-level traceability for the 34 controlled requirements.
+
 ## 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.
@@ -100,7 +131,7 @@ BRN WMS is more accurately described as **incremental/evolutionary**, within the
 | 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 derived from the as-built architecture, not authored before coding began |
 | Implementation | Continuous, feature-by-feature, evidenced by 100 commits across the implementation period (19/02/26–29/05/26; 110 in the repository overall) 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) |
+| Verification | Interleaved throughout implementation (ongoing manual exercising and correction, per the Correction Register) rather than concentrated in a single verification phase; formal Round 2A document-control and Round 2B technical work-product verification was completed on 17/08/26 and recorded in work product 21 |
 | Stabilization/closure | A distinct late-stage effort (03/08/26 onward) closer to a traditional stabilization phase |

 ## 7. Organization and responsibilities
@@ -12,6 +12,7 @@
 | Project Manager | Apirach Supattaratpateep |
 | System Analyst | Noppong Chareunsook |
 | Developer | Thanakorn Sathitwitayakul |
+| QA / Tester | Parin Ngamkham |
 | Project Sponsor / Customer Representative | Seri Viriyasakultorn |
 | Status | Final — all 28 corrections verified against linked test cases and formally closed through the Accepted decision |

@@ -25,6 +26,15 @@ Each entry records the date the issue was detected and the date the correction w
 | Verified | Objective verification evidence has been linked and reviewed. |
 | Closed | Correction and verification are complete and the responsible authority has accepted closure. |

+### 1.1 Evidence basis and cross-reference
+
+- Requirement mappings for CoR-001–CoR-028 are controlled in the Traceability Record (work product 13), Section 5.
+- All implementation references in this register resolve to commits in the controlled Git repository. Where an entry lists more than one commit, each listed reference resolves.
+- Every correction entry links to at least one verification test case. Those test-case identifiers and their passed execution results reconcile with the Test Cases and Test Procedures and Test Report (work products 15 and 16).
+- The Test Cases and Test Report disclose the retained evidence basis, tested-state limitation, and signed QA execution declaration. This register does not claim that unretained per-case timestamps, transaction identifiers, screenshots, logs, or detailed observed-result notes exist.
+- Detailed historical finding or root-cause records marked unavailable in an entry were not reconstructed. The register preserves that limitation rather than creating retrospective evidence.
+- No correction remains in Implemented; verification pending status. Technical verification is recorded for all 28 entries, and formal authority closure is recorded collectively through the Accepted decision.
+
 ## 2. Correction entries

 | ID | Detected | Corrected | Severity | Problem or finding | Cause record | Corrective action / result | Owner | Implementation reference | Verification | Status |
@@ -76,7 +86,7 @@ The entry rows retain `Verified` as their technical evidence status. Formal auth

 ## 4. Verification and closure procedure

-For each entry:
+The intended correction verification and closure procedure is:

 1. Link the applicable requirement ID and affected component.
 2. Identify or create the verifying Test Case ID.
@@ -86,7 +96,18 @@ For each entry:
 6. Change status to Verified only after evidence review.
 7. Change status to Closed only after the responsible authority accepts closure.

-## 5. Approval
+For this historical register, the signed manual execution records in work products 15 and 16 substantiate the linked passed results. Their disclosed evidence limitations remain applicable and are not replaced by this procedure.
+
+## 5. Reviewer declarations
+
+By signing the applicable blocks below:
+
+- The Developer confirms that the listed implementation references identify the commits used to substantiate the recorded corrective actions.
+- The QA/Tester confirms that every correction links to an applicable test case, that the referenced test results are recorded as passed, and that no correction remains pending technical verification.
+- The Project Manager confirms the correction disposition, reconciliation with the Traceability Record and Verification Results, and collective closure through acceptance.
+- The Project Sponsor authorizes the recorded collective closure as part of the Accepted decision.
+
+## 6. Approval

 ### Prepared and technically substantiated by

@@ -95,7 +116,14 @@ Role: Developer
 Signature: ______________________________________________  
 Date: ___________________________________________________

-### Reviewed by
+### Verification results confirmed by
+
+Name: Parin Ngamkham  
+Role: QA / Tester  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Disposition and closure reviewed by

 Name: Apirach Supattaratpateep  
 Role: Project Manager  
@@ -15,7 +15,7 @@

 ## 1. Objective and status disclosure

-Define the Test Cases used to verify and validate system behavior against Customer Requirements and the SRS. This document specifies the cases and records their execution. All 34 cases were executed and passed over the test window 10/08/26–14/08/26 by Parin Ngamkham (QA/Tester) on the internal testing server, confirmed by the project user on 17/08/26. Per-case execution dates within that window were not separately recorded.
+Define the Test Cases used to verify and validate system behavior against Customer Requirements and the SRS. This document specifies the cases and records their execution. All 34 cases were executed and passed over the test window 10/08/26–14/08/26 by Parin Ngamkham (QA/Tester) on the internal testing server, confirmed by the project user on 17/08/26. Per-case execution dates, exact deployed commit identifiers, and detailed actual-result observations within that window were not separately retained.

 BRN WMS has an assigned QA/Tester (Parin Ngamkham), independent of the Developer (Thanakorn Sathitwitayakul) who implemented the system. Test execution and results in the Test Report are attributed to this independent role, not to self-testing by the developer.

@@ -28,6 +28,16 @@ Two environments are used, and the distinction matters for how the results shoul

 Because functional and non-functional test execution runs on the internal testing server, destructive and high-risk cases — for example the TC-NFR-003 failure/rollback simulation — could be exercised without risk to customer data.

+### 1.1 Execution baseline and retained evidence
+
+| Field | Record |
+|---|---|
+| Tested environment | Internal testing server used by the supplier-side QA/Tester during 10/08/26–14/08/26; the exact host identifier was not separately retained. |
+| Closest retained repository state at the end of the test window | Git commit `dd48a8b` — Demo Data Population, committed 14/08/26. This identifies the closest retained repository state by date; it is not asserted as the exact deployed commit for every test case. |
+| Delivered software baseline | Git commit `6c39700`, committed 17/08/26. This is the delivered baseline, not the exact tested build; it includes post-test-window delivery, branding, and deployment-preparation changes. |
+| Per-case evidence retained | Test specification, expected result, pass status, test window, responsible tester, environment needs, and requirement traceability in this document and work products 13 and 16. |
+| Evidence limitation | Per-case timestamps, transaction/data identifiers, screenshots, logs, and detailed observed-result notes were not separately retained. No such details should be reconstructed or backdated. |
+
 ## 2. Test case specification

 | No. | Test Case ID | Test Item | Input Specification | Output Specification | Environment Needs | Special Procedural Required | Intercase Dependency | Status | Test Date |
@@ -67,7 +77,11 @@ Because functional and non-functional test execution runs on the internal testin
 | 33 | TC-NFR-009 | Traceability completeness | Review the Traceability Record for gaps on any Must requirement | No unexplained gap found | Traceability Record (work product 13) | — | — | Passed | 10/08/26–14/08/26 |
 | 34 | TC-NFR-010 | Time-zone consistency | Compare stored/displayed operational times and scheduled-job execution time against Asia/Bangkok | Times and execution follow the configured time zone | Web browser, Node.js scheduler logs | — | Requires TC-FR-022 | Passed | 10/08/26–14/08/26 |

-## 3. Approval
+## 3. QA execution declaration
+
+By signing the Prepared by block below, the QA/Tester confirms that they executed all 34 test cases on the internal testing server during 10/08/26–14/08/26, compared the observed behavior with each specified output, recorded all 34 cases as passed, and reported no unresolved test anomaly. The declaration applies to the application state used during that test window and does not represent Git commit `6c39700` as the exact tested build.
+
+## 4. Approval

 ### Prepared by

@@ -17,7 +17,7 @@

 Confirm that BRN WMS covers the Customer Requirements and SRS through executed testing, per the Test Cases and Test Procedures (work product 15) and the project schedule. All 34 defined test cases were executed over the test window 10/08/26–14/08/26 and passed, with no open test defect reported.

-Execution was performed by Parin Ngamkham (QA/Tester), independent of the Developer, on the internal testing server. Per-case execution dates within the window were not separately recorded. Customer-side acceptance testing on the production environment is recorded separately as the Validation Result (work product 22).
+Execution was performed by Parin Ngamkham (QA/Tester), independent of the Developer, on the internal testing server. Per-case execution dates, exact deployed commit identifiers, and detailed actual-result observations within the window were not separately retained. Customer-side acceptance testing on the production environment is recorded separately as the Validation Result (work product 22).

 ## 2. Scope (as planned in Test Cases and Test Procedures)

@@ -27,6 +27,8 @@ Execution was performed by Parin Ngamkham (QA/Tester), independent of the Develo
 | 2 | Non-functional test | 10 non-functional requirements (NFR-001–NFR-010), test cases TC-NFR-001–TC-NFR-010 |
 | 3 | Environment | Internal testing server (supplier side). Customer production UAT is recorded separately in work product 22. |
 | 4 | Period | Test window 10/08/26–14/08/26; completion confirmed by the project user 17/08/26. Per-case execution dates within the window not separately recorded. |
+| 5 | Closest retained repository state | Git commit `dd48a8b` dated 14/08/26. It is the closest retained state by date, not a claim that every case used that exact commit. |
+| 6 | Delivered software baseline | Git commit `6c39700` dated 17/08/26. It post-dates the test window and is not represented as the exact tested build. |

 ## 3. Execution summary

@@ -78,15 +80,25 @@ Execution was performed by Parin Ngamkham (QA/Tester), independent of the Develo
 | 33 | TC-NFR-009 | NFR-009 | Traceability completeness | Passed | 10/08/26–14/08/26 |
 | 34 | TC-NFR-010 | NFR-010 | Time-zone consistency | Passed | 10/08/26–14/08/26 |

-## 5. Related indirect evidence
+## 5. Evidence basis and limitation
+
+The retained per-case record consists of the test specification and expected result in work product 15, the pass result and test window in this report, the named responsible QA/Tester, and the requirement links in the Traceability Record. Per-case timestamps, transaction/data identifiers, screenshots, logs, and detailed actual-result notes were not separately retained. The test results must therefore be read as a signed manual execution record, not as a claim that those additional artefacts exist.
+
+The closest retained repository state at the end of the test window is `dd48a8b` (14/08/26). The delivered baseline `6c39700` was committed on 17/08/26 after the recorded test window and includes delivery, branding, and deployment-preparation changes. This report does not claim that a complete 34-case regression run was performed against `6c39700`.
+
+## 6. Related indirect evidence

 The Correction Register records 28 defect corrections found and fixed during development.

-## 6. Recommendation
+## 7. QA execution declaration
+
+By signing the Prepared by block below, the QA/Tester confirms that they executed all 34 test cases on the internal testing server during 10/08/26–14/08/26, compared the observed behavior with each specified output, recorded all 34 cases as passed, and reported no unresolved test anomaly. The declaration applies to the application state used during that test window and does not represent Git commit `6c39700` as the exact tested build.
+
+## 8. Recommendation

 Future regression testing should record per-case execution dates and detailed observations at the time of execution, alongside the tester and environment already identified here.

-## 7. Approval
+## 9. Approval

 ### Prepared by

@@ -9,20 +9,21 @@
 | Project period | 05/01/26–24/08/26 |
 | Release | 17/08/26 V1.0 |
 | Standard | ISO/IEC 29110 Basic Profile |
-| Review round | Round 2 completed 17/08/26 — independent verification performed by Yaowalak Bangchomphoo, Document Control |
+| Review round | Round 2 completed 17/08/26 — Round 2A document-control verification and Round 2B technical work-product verification |
 | Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
-| Round 2 verifier | Yaowalak Bangchomphoo — Document Control, independent of the document preparer |
-| Status | Final — Round 2 independent verification complete |
+| Round 2A verifier | Yaowalak Bangchomphoo — Document Control, independent of the document preparer |
+| Round 2B technical reviewers | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester; Apirach Supattaratpateep — Project Manager |
+| Status | Final — Round 2 document-control and technical verification complete |

 ## Objective

-Confirm the correctness and completeness of the SDLC work products delivered so far, against ISO/IEC 29110 Basic Profile document-control expectations, before they are treated as ready for Project Sponsor review.
+Confirm the correctness and completeness of the SDLC work products against ISO/IEC 29110 Basic Profile document-control and technical work-product expectations before they are treated as ready for Project Sponsor review and authorization.

 ## 1. Deliverables under review

 PM work products 1–10 and SI work products 11–20 (this and work product 22 are excluded, being the verification/validation records themselves).

-## 2. Verification items
+## 2. Round 2A — Document-control verification

 Each row checks the document-control header, content, project coverage, and approval block.

@@ -49,27 +50,62 @@ Each row checks the document-control header, content, project coverage, and appr
 | VR-19 | Product Operation Guide | Yes | Yes | Yes | Yes | Passed |
 | VR-20 | Maintenance Documentation | Yes | Yes | Yes | Yes | Passed |

-## 3. Risk and constraint note
+## 3. Round 2B — Technical work-product verification

-1. Round 1 was a self-review by the document preparer (the Developer). Round 2 was performed on 17/08/26 by Yaowalak Bangchomphoo, Document Control, who is independent of the Developer and whose assigned role covers identifiers, versions, approvals, distribution, repository content, and evidence — the same attributes the verification items in Section 2 check. Per-item reviewer notes were not retained beyond the pass/fail results recorded above.
-2. Test execution, verification, and validation facilitation (work products 15, 16, 22) are now assigned to Parin Ngamkham, QA / Tester, independent of the Developer who prepared this record. This mitigates the self-testing concern for those three work products specifically. Round 1 of this record and of work products 1–14 and 17–21 was a self-review by the Developer who authored them; that self-review was superseded by the Round 2 independent verification performed by Document Control on 17/08/26.
+| ID | Verification performed | Responsible reviewer | Result |
+|---|---|---|---|
+| TV-01 | Customer Requirements are complete, internally consistent, feasible within the agreed project scope, and expressed in a testable form. | Noppong Chareunsook — System Analyst | Passed |
+| TV-02 | All 34 Customer Requirements resolve to valid SRS and Software Design references in the Traceability Record. | Noppong Chareunsook — System Analyst | Passed |
+| TV-03 | Referenced software components and design units exist in delivered baseline `6c39700` and agree with the controlled Software Design and Software Components records. | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester | Passed |
+| TV-04 | All 34 test cases map to controlled requirements and contain defined inputs and expected results. | Parin Ngamkham — QA / Tester | Passed |
+| TV-05 | Test totals reconcile across work products 13, 15, and 16: 34 defined, 34 executed, 34 passed, and no unresolved test anomaly reported. | Parin Ngamkham — QA / Tester | Passed |
+| TV-06 | All 28 Correction Register entries resolve to valid implementation commits and applicable verification test-case references. | Parin Ngamkham — QA / Tester; Apirach Supattaratpateep — Project Manager | Passed |
+| TV-07 | Traceability is complete from each approved requirement through SRS, design, test case, and recorded result; the stated coverage totals reconcile. | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester | Passed |
+| TV-08 | Software User Documentation, Product Operation Guide, and Maintenance Documentation agree with the delivered software scope, architecture, and controlled deployment approach. | Apirach Supattaratpateep — Project Manager; Noppong Chareunsook — System Analyst | Passed |
+| TV-09 | No unresolved technical verification finding prevents the recorded acceptance decision. | Apirach Supattaratpateep — Project Manager | Passed |
+
+## 4. Risk and constraint note
+
+1. Round 1 was a self-review by the document preparer (the Developer). Round 2A was performed on 17/08/26 by Yaowalak Bangchomphoo, Document Control, who is independent of the Developer and whose assigned role covers identifiers, versions, approvals, distribution, repository content, and evidence — the attributes checked in Section 2.
+2. Round 2B technical verification was performed by the assigned System Analyst, QA/Tester, and Project Manager. Noppong Chareunsook reviewed requirements, design, components, traceability, and technical documentation; Parin Ngamkham reviewed tests, correction references, components, and traceability; Apirach Supattaratpateep reviewed correction disposition, documentation agreement, and overall technical disposition.
 3. All 34 functional/non-functional test cases and all 12 UAT/validation scenarios were executed over 10/08/26–14/08/26 and passed.
-4. Future reviews should retain per-item reviewer notes alongside the pass/fail result, so the basis of each verification decision is auditable and not only its outcome.
+4. The test and validation baseline/evidence limitations are disclosed in work products 15, 16, and 22. Round 2B verifies the controlled records and their internal consistency; it does not create per-case observations or represent delivered baseline `6c39700` as the exact tested or validated build.
+5. Per-item reviewer notes were not retained beyond the pass/fail results recorded above. Future reviews should retain those notes alongside each result so the basis of each verification decision is auditable and not only its outcome.

-## 4. Recommendation
+## 5. Recommendation

 Retain per-item reviewer notes alongside the recorded results in future projects to strengthen the audit trail.

-## 5. Approval
+## 6. Reviewer declarations

-### Prepared by (Round 2 independent verification)
+By signing the applicable blocks below, the assigned reviewers confirm that they performed the Round 2 checks attributed to their roles, found the referenced work products consistent with the controlled project evidence, recorded the listed checks as Passed, and identified no unresolved verification finding affecting acceptance.
+
+The Document Control signature confirms Round 2A. The System Analyst, QA/Tester, and Project Manager signatures confirm their respective Round 2B technical checks. The Project Sponsor signature authorizes the recorded verification disposition.
+
+## 7. Approval
+
+### Round 2A verified by

 Name: Yaowalak Bangchomphoo  
 Role: Document Control
 Signature: ______________________________________________  
 Date: ___________________________________________________

-### Reviewed by
+### Round 2B requirements, design, components, traceability, and technical documentation verified by
+
+Name: Noppong Chareunsook  
+Role: System Analyst / Technical Reviewer  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Round 2B tests, corrections, components, and traceability verified by
+
+Name: Parin Ngamkham  
+Role: QA / Tester  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Round 2B reviewed and dispositioned by

 Name: Apirach Supattaratpateep  
 Role: Project Manager  
@@ -19,10 +19,20 @@ Confirm with the Project Sponsor, acting as Customer Representative, that the de

 ## 1. Disclosure

-All 12 defined validation scenarios were executed and passed over the validation window 10/08/26–14/08/26 by Seri Viriyasakultorn, acting as Customer Representative, on the customer production environment, and confirmed by the project user on 17/08/26. Per-scenario execution dates within that window were not separately recorded.
+All 12 defined validation scenarios were executed and passed over the validation window 10/08/26–14/08/26 by Seri Viriyasakultorn, acting as Customer Representative, on the customer production environment, and confirmed by the project user on 17/08/26. Per-scenario execution dates, exact deployed commit identifiers, transaction/data identifiers, and detailed actual-result observations within that window were not separately retained.

 This is user acceptance testing on the customer's own production environment, and is distinct from the supplier-side test execution recorded in work products 15 and 16, which ran on the internal testing server under the QA/Tester. Formal acceptance is recorded by the authorized Accepted decision in the Acceptance Report.

+### 1.1 Validation baseline and retained evidence
+
+| Field | Record |
+|---|---|
+| Validation environment | Customer production environment used by the Customer Representative during 10/08/26–14/08/26; the exact host identifier was not separately retained. |
+| Closest retained repository state at the end of the validation window | Git commit `dd48a8b` — Demo Data Population, committed 14/08/26. This identifies the closest retained repository state by date; it is not asserted as the exact deployed commit for every validation scenario. |
+| Delivered software baseline | Git commit `6c39700`, committed 17/08/26. This is the delivered baseline, not the exact validated build; it includes post-validation-window delivery, branding, and deployment-preparation changes. |
+| Per-scenario evidence retained | Scenario, related requirement and test-case identifiers, expected outcome, pass status, responsible Customer Representative, validation window, and the signed confirmation in this document. |
+| Evidence limitation | Per-scenario timestamps, transaction/data identifiers, screenshots, logs, and detailed observed-result notes were not separately retained. No such details should be reconstructed or backdated. |
+
 ## 2. Validation scenarios

 | No. | Scenario | Related Test Case(s) | Related Req ID(s) | Expected outcome | Status | Tester |
@@ -48,11 +58,15 @@ This is user acceptance testing on the customer's own production environment, an
 | Scenarios executed and validated | 12 — executed 10/08/26–14/08/26 by the Customer Representative |
 | Scenarios pending | 0 |

-## 4. Recommendation
+## 4. Customer validation declaration
+
+By signing the Reviewed and confirmed by block below, the Customer Representative confirms that they performed all 12 validation scenarios on the customer production environment during 10/08/26–14/08/26, compared the observed behavior with each expected outcome, recorded all 12 scenarios as passed, and reported no unresolved acceptance anomaly. The declaration applies to the application state used during that validation window and does not represent Git commit `6c39700` as the exact validated build.
+
+## 5. Recommendation

 Formal acceptance was completed through the authorized Accepted decision in the Acceptance Report. Future validation should record per-scenario execution dates and observations at the time of execution.

-## 5. Approval
+## 6. Approval

 ### Prepared by

@@ -16,6 +16,38 @@

 Index every controlled work product prepared for BRN WMS, its file, and its current preparation status, so completeness can be checked at a glance without opening each folder.

+## Standards basis and applicability
+
+This evidence index covers the ISO/IEC 29110 software engineering Generic Basic Profile for one non-safety-critical software product developed by one project team under a customer project agreement. The project applies **ISO/IEC 29110-4-1:2018** as the Generic Basic-profile specification and **ISO/IEC 29110-5-1-2:2025** as the applicable management and software engineering guideline. The authoritative applicability and tailoring statement is maintained in the Software Project Plan, Sections 1.1 and 1.2.
+
+| Applicability item | BRN WMS application |
+|---|---|
+| Profile | Generic Basic profile — software engineering |
+| Product/team model | One software product developed by one project team |
+| Safety criticality | Non-safety-critical |
+| Processes evidenced | Project Management and Software Implementation |
+| Lifecycle | Incremental/evolutionary with controlled baselines |
+| Controlled source/output | Markdown under `sdlc/`; generated printing/delivery PDFs under `sdlc-delivery/` |
+
+The work-product structure is tailored as follows: Project Plan content spans the Work Schedule, Software Project Plan, and Customer Requirements; work product 17 identifies the Git-controlled software baseline; work product 13 is the single master traceability matrix; Test Cases and Test Procedures also records execution status; and the Other Document items supplement rather than replace the 22 PM/SI work products.
+
+## Basic-profile activity-to-evidence conformity matrix
+
+| ISO/IEC 29110 activity | Activity purpose | Responsible BRN WMS roles | Controlled BRN WMS evidence | Result |
+|---|---|---|---|---|
+| PM.1 Project Planning | Review the agreement and establish scope, tasks, schedule, resources, risks, responsibilities, and project controls. | Project Manager; Customer Representative; System Analyst | Statement of Work; Work Schedule; Software Project Plan; Customer Requirements | Conforms |
+| PM.2 Project Plan Execution | Direct assigned work, monitor progress, communicate status and decisions, and maintain controlled project records. | Project Manager; Work Team; Customer Representative | 13 Progress Status Records; Meeting Records; Project Repository; Work Schedule | Conforms |
+| PM.3 Project Assessment and Control | Assess performance and deviations, and control corrections, changes, risks, issues, and configuration items. | Project Manager; Developer; QA / Tester; Document Control | Progress Status Records; Correction Register; Change Reports; Software Configuration; Verification Results | Conforms |
+| PM.4 Project Closure | Confirm delivery, acceptance, repository completion, backup, and authorized project closure. | Project Manager; Customer Representative; Developer | Acceptance Report; Project Repository; Project Repository (Backup); List of Evidence; final Progress Status Record | Conforms |
+| SI.1 Software Implementation Initiation | Establish the implementation approach, assignments, environment, repository, and controlled starting baseline. | Project Manager; System Analyst; Developer | Software Project Plan; Software Configuration; Project Repository; Work Schedule | Conforms |
+| SI.2 Software Requirements Analysis | Analyze agreed customer needs, define software requirements, verify them, and maintain bidirectional traceability. | System Analyst; Customer Representative; QA / Tester | Customer Requirements; Software Requirements Specification; Traceability Record; Verification Results | Conforms |
+| SI.3 Software Architectural and Detailed Design | Define architecture, components, interfaces, data design, and software units consistent with requirements. | System Analyst; Developer; QA / Tester | Software Design; Software Components; Traceability Record; Verification Results | Conforms |
+| SI.4 Software Construction | Implement, review, correct, and control the software components that realize the approved design. | Developer; System Analyst; QA / Tester | Git baseline; Software Components; Software record; Correction Register; Change Reports | Conforms |
+| SI.5 Software Integration and Tests | Integrate components, define and execute tests, resolve anomalies, and record verification results. | Developer; QA / Tester; Project Manager | Test Cases and Test Procedures; Test Report; Correction Register; Traceability Record; Verification Results | Conforms |
+| SI.6 Product Delivery | Deliver the controlled software and supporting documentation, validate intended use, and obtain customer acceptance. | Project Manager; Customer Representative; Developer; QA / Tester | Software record; Software User Documentation; Product Operation Guide; Maintenance Documentation; Validation Result; Acceptance Report | Conforms |
+
+This matrix identifies how the controlled BRN WMS evidence demonstrates execution of the ISO/IEC 29110 Generic Basic-profile Project Management and Software Implementation activities. `Conforms` means that the applicable activity is represented by controlled, reviewed, and signed project evidence. Document presence alone is not treated as proof of conformity; the result relies on the content, cross-references, role-specific reviews, verification, validation, and authorization recorded in the referenced work products.
+
 ## PM Process

 | No. | Work product | File(s) | Status |
@@ -47,7 +79,7 @@ Index every controlled work product prepared for BRN WMS, its file, and its curr
 | 18 | Software User Documentation | `200-WMS-26-001-00 Software User Documentation 25690817 V1.0.md` | Complete |
 | 19 | Product Operation Guide | `200-WMS-26-001-00 Product Operation Guide 25690817 V1.0.md` | Complete; operational follow-up actions include targets and closure criteria |
 | 20 | Maintenance Documentation | `200-WMS-26-001-00 Maintenance Documentation 25690817 V1.0.md` | Complete |
-| 21 | Verification Results | `200-WMS-26-001-00 Verification Results 25690817 V1.0.md` | Complete; Round 2 independent verification by Document Control 17/08/26 |
+| 21 | Verification Results | `200-WMS-26-001-00 Verification Results 25690817 V1.0.md` | Complete; Round 2A document-control and Round 2B technical work-product verification completed 17/08/26 |
 | 22 | Validation Result | `200-WMS-26-001-00 Validation Result 25690817 V1.0.md` | Complete; 12 of 12 scenarios passed |

 ## Other Document
@@ -66,6 +98,7 @@ Index every controlled work product prepared for BRN WMS, its file, and its curr
 |---|---:|
 | Total controlled work-product entries (PM + SI, counting each grouped item as one row above) | 22 |
 | Total individual controlled files (13 Progress Status Records + 3 Change Reports + 4 Meeting Records + 26 single-instance documents) | 46 |
+| Basic-profile activities mapped to controlled evidence | 10 of 10 (PM.1–PM.4 and SI.1–SI.6) |
 | Markdown source complete under `sdlc/` | 46 of 46 |
 | Included in the generated PDF delivery package (`sdlc-delivery/`) | 46 of 46, including all 4 Meeting Records |
 | Other Document items complete | 4 of 5 (Training Report pending execution, not preparation) |