## Introduction

# Introduction

This document defines the functional and non-functional requirements, architectural constraints, and current limitations for the order management and payment processing system. The primary focus is on the capabilities and boundaries of the existing system, specifically regarding order creation, payment processing, notification handling, and CSV/batch import features.

The current order management system supports only single-entry order creation, requiring each order to be created individually via the REST API. There is no functionality for bulk or batch order creation, nor is there any endpoint or mechanism to upload and process order data from files such as CSV or Excel. Payment processing is similarly constrained, with each order requiring an individual payment API call; batch payment APIs are not available. Notifications related to orders are also sent individually, with no support for bulk notification processing. These limitations significantly impact operational efficiency, especially for business customers who have expressed a need to import large numbers of orders (ranging from 100 to 10,000) via CSV files.

The system’s architecture enforces sequential processing for order creation, payment, and notification flows, with no parallel or queue-based processing capabilities. This sequential design results in increased latency for large-scale operations, as each step (order creation, payment, notification) must complete before the next begins. Additionally, there are no mechanisms for progress tracking of batch operations or for handling partial failures within a batch; if an error occurs, there is no built-in way to continue processing the remaining items or to track which items succeeded or failed.

These constraints are critical to understanding the current system’s operational boundaries and must be considered in any future enhancements or migration planning. Any feature that requires capabilities beyond these limitations will necessitate architectural changes across multiple services.

The following sections provide detailed requirements, constraints, and system behaviors, as well as references to specific implementation details and known limitations.

**References:**
- [KB-146a6a29-932f-485d-96d6-6a92ee610336]
- [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c]
- [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8]
- [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]
- [KB-150eb89c-77b0-415b-a547-3ed0502eec24]
- [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1]
- [KB-1603dccf-0e13-426d-a4c3-527af9e69c16]
- [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

## Getting Started

# 1. Getting Started

This section provides an overview of the system’s capabilities, access methods, and current limitations to guide new users and administrators in initial system usage and onboarding.

---

## 1.1 System Overview

The system is a web-based order management platform for EC site operations. The frontend is implemented as a React single-page application (SPA) that connects to three backend microservices via REST API. All inter-service communication is synchronous REST over HTTP. There are no message brokers or asynchronous event buses in the architecture. Each service is responsible for a specific business domain, such as order management, payment processing, and notification delivery. [KB-050d0be4-11bc-4945-80e4-1f59d3187e45]

---

## 1.2 Key Features

- **Order Management:** Create, view, update, and cancel individual orders. Each order includes customer information and order item details. [KB-0e0f1dd0-0f46-4d13-a092-e3cdc6fdd205]
- **Payment Processing:** Payments are processed per order. Each payment transaction is handled individually; batch or aggregate payments are not supported. [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c]
- **Notification Service:** Order-related notifications (e.g., order confirmation, shipping, cancellation) are sent per order. There is no bulk notification capability. [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]
- **Order Detail View:** For each order, the system fetches and displays order data, payment status, and notification history in parallel from all three services. [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

---

## 1.3 Accessing the System

- **Web Interface:** Users access the system via a React SPA. The interface provides search, filtering, and sorting for orders, as well as forms for single order creation and management. [KB-16181d30-2dd3-421e-bab0-939cd85255d2]
- **API Endpoints:** All business operations are exposed via RESTful endpoints. Major resources include:
  - `/api/v1/orders` for order management
  - `/api/v1/payments` for payment processing
  - `/api/v1/notifications` for notification delivery [KB-0972bd0e-7d3f-4b2c-a364-813e023a3495]

---

## 1.4 Current System Limitations

The following limitations define the boundaries of the current system. Any feature requiring capabilities beyond these will require architectural changes across multiple services.

| ID      | Limitation                                                                                                         | Impact Area          | Severity   |
|---------|--------------------------------------------------------------------------------------------------------------------|----------------------|------------|
| LIM-001 | **Order creation is single-entry only.** No bulk or batch order creation capability exists. Orders can only be created one at a time via the REST API. | Order Service        | High       |
| LIM-002 | **No CSV/file-based order import functionality.** There is no endpoint or mechanism to upload and process order data from files (CSV, Excel, etc.).    | Order Service        | High       |
| LIM-003 | **Payment processing handles one transaction at a time.** No batch payment API exists. Each order requires an individual payment API call.              | Payment Service      | High       |
| LIM-004 | **Notifications are sent individually per order.** No bulk notification capability exists. Each notification requires a separate API call.              | Notification Service | Medium     |
| LIM-005 | **Cross-service calls are sequential.** Order creation flow (Order → Payment → Notification) executes sequentially. No parallel processing of payment and notification. | All Services         | Medium     |
| LIM-006 | **No progress tracking for batch operations.** The system has no mechanism to track progress of multi-item operations because no batch operations exist. | All Services         | Medium     |

[KB-146a6a29-932f-485d-96d6-6a92ee610336]

**UI Note:** The order management screen displays a “CSV Import (Not Implemented)” button in a disabled state and an amber warning banner indicating that CSV import is not available. [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

---

## 1.5 Security and Compliance

- All inter-service communication is secured using TLS 1.3.
- Authentication and authorization are enforced at the API level.
- No PHI or sensitive information is exposed in error responses. [KB-10300d8a-a98a-4726-b7e6-4f9f3627b7e6]
- System logs and audit trails are maintained in accordance with regulatory requirements.

---

## 1.6 Getting Help

For questions or support, contact the system administrator or refer to the internal documentation portal.

---

**End of Getting Started**

## Build and Test

# 6. Build and Test

This section describes the build and test processes for the system, including implementation constraints, testing requirements, and compliance with ISO-29148 for traceability and quality assurance.

---

## 6.1 Build Process

### 6.1.1 Technology Stack and Build Environment

The system is built using the following technology stack:

| Component            | Technology                      | Version      | End of Life                   |
|----------------------|---------------------------------|--------------|-------------------------------|
| Programming Language | Visual Basic 6.0 (legacy)       | SP6          | 2008 (extended support ended) |
| Programming Language | Java (Spring Boot migration)    | 6.x          | Active                        |
| Runtime              | VB6 Runtime (MSVBVM60.dll)      | 6.0 SP6      | Included in Windows           |
| UI Framework         | VB6 WinForms (legacy)           | 6.0          | N/A                           |
| UI Framework         | React SPA (Spring Boot system)  | N/A          | Active                        |
| Data Access          | ADO (ActiveX Data Objects)      | 2.x          | Legacy                        |
| Data Access          | Spring Data JPA + Hibernate     | 6.4          | Active                        |
| Database             | SQL Server 2012 + MS Access     | Legacy       | EOL                           |
| Database             | PostgreSQL 16 (AWS RDS)         | Target       | Active                        |
| Reporting            | Crystal Reports XI (legacy)      | Legacy       | EOL                           |
| Reporting            | JasperReports (migration)        | Target       | Active                        |  
[KB-03d0d4be-6781-4fc5-af90-de8b326616c0] [KB-17a58f06-2387-412d-bfbe-2f4d751e1d7e] [KB-154a8a35-d445-4bba-9ae4-19c45a53d758]

### 6.1.2 Build Automation

- The migration to Spring Boot uses a CI/CD pipeline with automated builds, dependency scanning (OWASP Dependency-Check), and test execution.
- Flyway is used for database schema migrations to PostgreSQL.  
[KB-0a1640fc-f63e-4c6b-8191-220e34d8af3f] [KB-15aa67c7-0ace-4d42-8c36-b17874f98d95]

---

## 6.2 Test Strategy

### 6.2.1 Test Coverage Requirements

- **Unit Test Coverage:** Minimum 80% line coverage for all new Spring Boot services.
- **Integration Testing:** All service interfaces (REST APIs) must be validated against PostgreSQL.
- **Security Testing:** Authentication, authorization, and input validation must be tested (see Section 6.3).
- **Performance Testing:** System must meet or exceed legacy baseline for all key metrics.
- **Accessibility Testing:** React UI must meet WCAG 2.1 AA compliance.
- **Code Review:** All code must be reviewed by a senior developer and undergo a security review.
[KB-0a1640fc-f63e-4c6b-8191-220e34d8af3f]

### 6.2.2 System and Acceptance Testing

#### 6.2.2.1 Parallel Run and Data Validation

- **Parallel Run:** Both legacy and new systems are operated in parallel for a minimum of 2 weeks.
- **Data Validation:** Record counts, checksums, and financial balances are compared between systems. Tolerance for financial totals is $0.01.
- **Acceptance Criteria:** All comparison reports must show zero or within-tolerance differences for critical data sets.
[KB-05e90e5d-09da-4f67-85af-8f2be11cd2ce] [KB-092b662f-1233-4421-a137-d96b5c1a2082] [KB-0368630b-7eb5-445e-aa3b-de044dd2e57a]

| Comparison Test                 | Tolerance   | Alert Level         |
|---------------------------------|-------------|---------------------|
| New patient registrations match | 0           | Critical            |
| Appointment count matches       | 0           | Critical            |
| Daily financial totals match    | $0.01       | Critical            |
| Claims submitted match          | 0           | High                |
| Payments posted match           | $0.01       | Critical            |
| Clinical note count matches     | 0           | High                |
| User login count comparison     | ±5%         | Low (expected diff) |
[KB-092b662f-1233-4421-a137-d96b5c1a2082]

#### 6.2.2.2 User Acceptance Testing (UAT)

- UAT is performed by end users from each department (front desk, billing, clinical, admin).
- Each module is tested in sequence, with sign-off required before go-live.
[KB-169a3eb6-41b7-4fce-a195-bdee1dbb5c1dd]

|   Phase | Module               | UAT Participants                     | Duration   | Status   |
|---------|----------------------|--------------------------------------|------------|----------|
|       1 | Patient Registration | Front desk staff (3), Office mgr (1) | 1 week     | Complete |
|       1 | Scheduling           | Front desk (3), Dentists (2)         | 1 week     | Complete |
|       2 | Insurance / Billing  | Billing staff (4), Office mgr (1)    | 2 weeks    | Planned  |
|       3 | Clinical Notes       | Dentists (4), Hygienists (3)         | 2 weeks    | Planned  |
|       4 | Imaging / Labs / Rx  | Dentists (4), Hygienists (3)         | 1 week     | Planned  |
|       5 | Reports / Admin      | Office mgr (2), IT (1)               | 1 week     | Planned  |
[KB-169a3eb6-41b7-4fce-a195-bdee1dbb5c1dd]

---

## 6.3 Security and Compliance Testing

- **Authentication and Authorization:** OAuth 2.0 Resource Server with Azure AD integration. Method-level authorization is enforced.
- **CSRF Protection:** SameSite cookies and CSRF tokens.
- **Input Validation:** Bean Validation and custom validators.
- **Output Encoding:** OWASP Java Encoder.
- **Session Management:** Stateless JWT, with Redis token blacklist.
- **Dependency Scanning:** OWASP Dependency-Check in CI/CD.
[KB-0910e88e-c115-4412-a137-d96b5c1a2082]

- **Audit Logging:** PHI access and modification events are logged and retained per HIPAA requirements.
- **Error Handling:** Production error responses must not expose PHI, stack traces, SQL queries, internal file paths, server names, or framework version information.
[KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4] [KB-140ca7f3-3348-4419-b06b-89561882a35e]

---

## 6.4 Performance Testing

| Metric                       | Legacy Baseline   | Target   | Measurement Method      |
|------------------------------|-------------------|----------|-------------------------|
| Patient search response time | 2.0s              | ≤2.0s    | Application metrics     |
| Appointment search time      | 2.5s              | ≤2.5s    | Application metrics     |
| Claims submission time       | 1.5s              | ≤1.5s    | Application metrics     |
| Payment posting time         | 1.0s              | ≤1.0s    | Application metrics     |
| Report generation time       | 10.0s             | ≤10.0s   | Application metrics     |
[KB-05e90e5d-09da-4f67-85af-8f2be11cd2ce]

---

## 6.5 Migration and Rollback Testing

- **Data migration is executed and verified** (record count, checksum).
- **Rollback plan is tested** (see Rollback_and_Contingency_Plan.md).
- **Legacy modules are disabled (read-only mode) after migration.**
- **Post-migration support:** 2 weeks of hypercare with dedicated support.
[KB-05e90e5d-09da-4f67-85af-8f2be11cd2ce]

| Test                              | Frequency     | Last Test   | Next Test   | Result   |
|-----------------------------------|---------------|-------------|-------------|----------|
| Blue/green deployment rollback    | Monthly       | 2025-07-15  | 2025-08-15  | Pass     |
| Database backup restoration       | Monthly       | 2025-07-15  | 2025-08-15  | Pass     |
| Full migration rollback (staging) | Quarterly     | 2025-06-01  | 2025-09-01  | Pass     |
| Service-level rollback            | Monthly       | 2025-07-15  | 2025-08-15  | Pass     |
[KB-0e7db777-ce75-42c0-aac9-256614f5e8a4] [KB-190fe16f-a70b-4fa5-869a-fcb047547798]

---

## 6.6 Traceability and Compliance

- All requirements are traceable to test cases and acceptance criteria.
- Compliance with HIPAA, including audit logging, access controls, and PHI handling, is verified through dedicated test cases and audit reviews.
[KB-1554a441-9086-4371-85f6-cb4d7472ee1b] [KB-0f3989d4-36c1-4054-923c-c250f04c3ec3]

---

## 6.7 Outstanding Gaps

[GAP: Missing data for Build and Test]  
If additional details are required for specific modules or test cases, they must be documented and referenced here.

---

**End of Section**

## Contribute

[GAP: Missing data for Contribute]