ASF_01_sys_sw_arch/draft/System Design old/System Review Checklist.md

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