# System Review Checklist

**Project:** Sensor Hub – Poultry Farm Automation  
**Scope:** Sensor Hub (Sub-Hub Only)  
**Purpose:** Verify system readiness before FRD/SAD generation and AI-assisted implementation

## 1\. Requirements Completeness Review

### 1.1 Feature Coverage

✔ All major functional domains defined:

*   ☐ Data Acquisition (DAQ)
    
*   ☐ Data Quality & Calibration (DQC)
    
*   ☐ Communication (COM)
    
*   ☐ Diagnostics & Health (DIAG)
    
*   ☐ Persistence & Data Management (DATA)
    
*   ☐ OTA Update (OTA)
    
*   ☐ Security & Safety (SEC)
    
*   ☐ System Management & HMI (SYS)
    

**Acceptance Criteria:**  
No functional behavior is undocumented or implicit.

### 1.2 Requirement Quality

For **each system requirement**, verify:

*   ☐ Uses “SHALL”
    
*   ☐ Is testable
    
*   ☐ Is unambiguous
    
*   ☐ Has a unique ID
    
*   ☐ Is traceable to a feature
    

**Red Flags:**

*   Vague timing (“fast”, “real-time”)
    
*   Mixed requirements (“shall… and …”)
    
*   Implementation leakage (“using mutex”)
    

## 2\. Architectural Soundness Review

### 2.1 Layering & Separation of Concerns

*   ☐ Hardware access isolated
    
*   ☐ No feature bypasses System Manager
    
*   ☐ Persistence accessed only via DP
    
*   ☐ HMI does not modify safety-critical configuration
    

**Fail Condition:**  
Any feature directly accesses hardware or storage without abstraction.

### 2.2 State Machine Validity

*   ☐ All system states defined
    
*   ☐ Valid transitions documented
    
*   ☐ Illegal transitions blocked
    
*   ☐ Feature behavior defined per state
    

**States to Verify:**

*   INIT
    
*   IDLE
    
*   RUNNING
    
*   DEGRADED
    
*   OTA\_UPDATE
    
*   TEARDOWN
    
*   ERROR
    

## 3\. Cross-Feature Constraint Compliance

### 3.1 Constraint Awareness

*   ☐ Each feature respects cross-feature constraints
    
*   ☐ No constraint contradicts a requirement
    
*   ☐ Constraints are globally enforceable
    

### 3.2 Conflict Resolution

Check for conflicts such as:

*   ☐ OTA vs DAQ timing
    
*   ☐ Persistence vs Power Loss
    
*   ☐ Diagnostics vs Real-Time Tasks
    
*   ☐ Debug vs Secure Boot
    

**Acceptance:**  
Conflicts resolved via priority rules or system state restrictions.

## 4\. Timing & Performance Review

### 4.1 Real-Time Constraints

*   ☐ High-frequency sampling bounded
    
*   ☐ Worst-case execution time considered
    
*   ☐ Non-blocking design enforced
    

### 4.2 Resource Usage

*   ☐ CPU usage bounded
    
*   ☐ RAM usage predictable
    
*   ☐ Stack sizes justified
    
*   ☐ Heap usage minimized in runtime
    

## 5\. Reliability & Fault Handling Review

### 5.1 Fault Detection

*   ☐ Sensor failure detection defined
    
*   ☐ Communication failure detection defined
    
*   ☐ Storage failure detection defined
    

### 5.2 Fault Response

*   ☐ Graceful degradation defined
    
*   ☐ Diagnostics logged
    
*   ☐ System state updated appropriately
    

## 6\. Security Review

### 6.1 Boot & Firmware

*   ☐ Secure boot enforced
    
*   ☐ Firmware integrity verified
    
*   ☐ Rollback prevention defined
    

### 6.2 Communication

*   ☐ Encryption mandatory
    
*   ☐ Authentication required
    
*   ☐ Key management strategy defined
    

### 6.3 Debug Access

*   ☐ Debug sessions authenticated
    
*   ☐ Debug disabled in production unless authorized
    
*   ☐ Debug cannot bypass security or safety
    

## 7\. Data Management Review

### 7.1 Data Ownership

*   ☐ Single source of truth enforced
    
*   ☐ Clear ownership per data type
    
*   ☐ No duplicated persistent data
    

### 7.2 Persistence Safety

*   ☐ Safe writes during state transitions
    
*   ☐ Power-loss tolerance defined
    
*   ☐ Data recovery defined
    

## 8\. HMI & Usability Review (OLED + Buttons)

### 8.1 Display Content

*   ☐ Connectivity status
    
*   ☐ System status
    
*   ☐ Connected sensors
    
*   ☐ Time & date
    

### 8.2 Navigation Logic

*   ☐ Menu hierarchy defined
    
*   ☐ Button behavior consistent
    
*   ☐ No destructive action via UI
    

## 9\. Standards & Compliance Readiness

### 9.1 IEC 61499 Mapping Readiness

*   ☐ Functional blocks identifiable
    
*   ☐ Event/data separation respected
    
*   ☐ Distributed execution possible
    

### 9.2 ISA-95 Alignment Readiness

*   ☐ Sensor Hub maps to Level 1/2
    
*   ☐ Clear boundary to Level 3/4
    
*   ☐ No business logic leakage
    

## 10\. AI Readiness Review

### 10.1 Prompt Compatibility

*   ☐ Features modular
    
*   ☐ Requirements structured
    
*   ☐ Architecture explicit
    

### 10.2 Tool Handoff Readiness

*   ☐ Claude can generate FRD/SAD
    
*   ☐ Mermaid diagrams derivable
    
*   ☐ DeepSeek can critique logic
    
*   ☐ Cursor rules enforce constraints
    

## Final Gate Decision

### GO / NO-GO Criteria

**GO** if:

*   All sections ≥ 90% checked
    
*   No critical architectural violation
    
*   Security constraints enforced
    

**NO-GO** if:

*   Missing system states
    
*   Undefined failure behavior
    
*   Security gaps
    
*   Persistence inconsistency