cleanup
This commit is contained in:
304
draft/System Design old/System Review Checklist.md
Normal file
304
draft/System Design old/System Review Checklist.md
Normal file
@@ -0,0 +1,304 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user