DRI Text Analysis Method (Data-Rule-Interaction Text Analysis)

An analysis standard that reduces and decomposes natural language business requirements into the cornerstones of system design. Essentially, it is extracting the ubiquitous language in requirements engineering, which is of great value for subsequent object-oriented design, database modeling, interface design, and even code scaffolding generation.

When to Use This Skill

Use this skill when users:

Provide a section of business requirement description and need to extract the system's data model, business rules, and interaction boundaries from it
Say "Help me analyze this requirement" or "Decompose this text into system design"
Say "Perform DRI analysis on the project" or "Parse the requirement document using the DRI method"
Want to convert requirement documents into structured architectural abstractions before writing code
Need to check if there are gaps in requirements (e.g., data without interaction, interaction without rules)
Are doing domain modeling and need to extract concepts such as entities, services, and interfaces from natural language
Want to decompose long requirement documents into development tasks assignable to different technical components

Core Concepts

Three-Dimensional Abstract Model

The core purpose of a software system is to: Receive external instructions, process information, and save state. The DRI model fully covers this with three dimensions:

┌──────────────────────────────────────────────┐
│                                              │
│   Trigger(I) ──→ Execute(R) ──→ Read/Write(D)           │
│                                              │
│   Feedback(I) ←── Callback(R) ←── Change(D)           │
│                                              │
└──────────────────────────────────────────────┘

Data is the body, Rule is the engine, and Interaction is the boundary.

This model is highly consistent with the classic ECB Pattern (Entity-Control-Boundary):

DRI Concept	ECB Pattern	Hexagonal Architecture	Clean Architecture
Data (D)	Entity	Domain Model	Entities
Rule (R)	Control	Application Service	Use Cases
Interaction (I)	Boundary	Port / Adapter	Interface Adapters

[D] Data — The "State" and "Assets" of the System

Answers "What does the system have?".

Part-of-Speech Characteristics: Nouns, noun phrases, specific values, state enumeration words.
Identification Basis: Does it represent information that needs to be "remembered", "stored", "queried" or "updated" in the system?
Subcategories:
- Entity: Business objects with unique identifiers and lifecycles (e.g.
```
monitoring node
```
  ,
```
frame
```
  )
- Attribute: Specific characteristic values of entities (e.g.
```
temperature value
```
  ,
```
operating status
```
  )
- Constant/Configuration: Thresholds, enumeration values, etc. (e.g.
```
80 degrees
```
  ,
```
abnormal
```
  )
- Stream/Resource: Transient or persistent data resources (e.g.
```
video stream
```
  ,
```
on-site screenshot
```
  )
- Message: Data carriers transmitted between systems (e.g.
```
alarm notification
```
  )
Typical Vocabulary: record, value, status, attribute, configuration, snapshot, list, model, context

[R] Rule — The "Engine" and "Rules" of the System

Answers "How does the system operate?".

Part-of-Speech Characteristics: Verbs representing calculation, judgment, comparison, and conditional conjunctions.
Identification Basis: Does it define the conditions for change? Does it include If-Then logic, mathematical operations, or constraints?
Subcategories:
- Condition: Trigger conditions for If-Then logic (e.g.
```
If...exceeds...for 3 consecutive seconds
```
  )
- Threshold Comparison: Numeric comparison operations (e.g.
```
exceeds
```
  ,
```
greater than
```
  ,
```
equal to
```
  )
- Temporal Constraint: Judgments involving time windows (e.g.
```
3 consecutive seconds
```
  ,
```
every 5 minutes
```
  )
- Domain Service: Encapsulated complex business logic chains (e.g.
```
fire intelligent reasoning logic
```
  )
- State Transition: State transition actions of entities (e.g.
```
update to abnormal
```
  )
- Data Processing: Data conversion, extraction, calculation (e.g.
```
extract temperature
```
  ,
```
calculate average value
```
  )
Typical Vocabulary: if, judge, exceed, match, calculate, filter, verify, trigger, convert

[I] Interaction — The "Boundary" and "Touchpoints" of the System

Answers "Who triggers the system, and who does it affect?".

Part-of-Speech Characteristics: Verb-object phrases representing action transfer and boundary crossing, proper nouns of external systems/physical devices.
Identification Basis: Does it involve information input/output (I/O)? Is it a contact point between the system and the external world?
Subcategories:
- Inbound: Data inflow from external to system (e.g.
```
receive video stream
```
  ,
```
user click
```
  )
- Outbound: Data outflow from system to external (e.g.
```
send notification
```
  ,
```
render frame
```
  )
- External Actor: People or third parties interacting with the system (e.g.
```
administrator
```
  ,
```
player
```
  )
- External Device/Channel: Physical or logical carrier of I/O (e.g.
```
camera
```
  ,
```
WeCom
```
  ,
```
API interface
```
  )
Typical Vocabulary: click, receive, send, interface, push, display, upload, download, render

[O] Other

Grammatical structure words such as conjunctions, prepositions, pronouns (e.g. "的", "地", "将", "和" in Chinese) have no practical abstract value in system modeling and are ignored during annotation.

Analysis Process

Step 1: Inline Word-by-Word Annotation

Decompose the original text word by word or phrase by phrase, and follow key phrases with square bracket tags.

Annotation Syntax:

Word[Tag:Subcategory]

Tag values:

D:entity

D:attribute

D:constant

D:stream-data

D:message

D:state-enum

R:condition-start

R:threshold-comparison

R:temporal-constraint

R:domain-service

R:state-transition

R:processing-action

I:input-device

I:input-action

I:output-channel

I:output-action

I:external-actor

I:recipient

Step 2: Concept Abstract Summary Table

Merge and refine the annotation results, and output as a structured table:

Abstract Dimension	Extracted Specific Concepts	System Design Mapping	Notes/Design Suggestions
Data (Data)	All content with D tags extracted from annotations	Domain Model/Entity, Configuration Item, Persistence Table Design	Transient vs Persistent, Configurable vs Hard-coded
Rule (Rule)	All content with R tags extracted from annotations	Core Algorithm, Domain Service, State Machine	Parts that require focused unit testing
Interaction (Interaction)	All content with I tags extracted from annotations	Inbound Gateway, Outbound Gateway, UI Component	Fault tolerance, Retry, Concurrent Processing

Step 3: Gap Check

Perform D-R-I cross-validation after completing the table:

Data Without Interaction: Data exists but no interaction to create/modify/read it → Requirements may be missing input/output.
Interaction Without Rule: Interaction exists (e.g., receiving data) but no rule to process it → Requirements may be missing business logic.
Rule Without Data: Rule exists but no target data to operate on → Rule may be redundant or data definition is missing.
Isolated Entity: A data entity is neither referenced by rules nor exposed through interaction → May be over-design.

Complete Case

Original Text

"The monitoring system receives video streams in real time through cameras, extracts the temperature value of the current frame. If the temperature exceeds 80 degrees for 3 consecutive seconds, it triggers the fire intelligent reasoning logic. The system automatically sends an alarm notification containing on-site screenshots to the administrator via WeCom, and updates the operating status of the monitoring node in the database to abnormal."

Step 1: Inline Annotation

Monitoring system
[I:recipient]
via Camera
[I:input-device]
real-time receive
[I:input-action]
video stream
[D:stream-data]
, extract
[R:processing-action]
current frame
[D:entity]
's temperature value
[D:attribute]
. If
[R:condition-start]
temperature
[D:attribute]
3 consecutive seconds
[R:temporal-constraint]
exceeds
[R:threshold-comparison]
80 degrees
[D:constant]
, then trigger
[R:state-transition]
fire intelligent reasoning logic
[R:domain-service]
, system automatically via WeCom
[I:output-channel]
to administrator
[I:external-actor]
send
[I:output-action]
containing on-site screenshot
[D:stream-data]
alarm notification
[D:message]
, and in database update the monitoring node
[D:entity]
's operating status
[D:attribute]
to
[R:state-transition]
abnormal
[D:state-enum]
.

Step 2: Concept Abstract Summary Table

Abstract Dimension	Extracted Specific Concepts	System Design Mapping	Notes/Design Suggestions
Data (Data)	Video stream, frame, temperature value	Domain Model: `VideoFrame` , `Temperature`	Video stream is transient in-memory data, frames may need caching
	80 degrees (threshold constant)	Configuration Item: `ALARM_TEMP_THRESHOLD = 80`	Should be designed as a configurable parameter instead of hard-coded
	Alarm notification, on-site screenshot	Message/Resource: `AlarmMessage` , `ImageResource`	Screenshots need to be persisted to object storage, notifications should be logged
	Monitoring node, operating status, abnormal	Persistent Entity: `MonitorNode (Status: Normal/Error)`	Corresponding to the node table and status enumeration field in the database
Rule (Rule)	Extract (temperature)	Data Processing: Image recognition/sensor data parsing algorithm	Convert unstructured data to structured data
	If...exceeds for 3 consecutive seconds	Reasoning Engine/State Machine: Time-series data sliding window judgment	Core business rule, requires focused unit testing to prevent false alarms
	Trigger fire intelligent reasoning logic	Domain Service: `FireReasoningService`	Encapsulates complex judgment chains
	Update to (abnormal status)	State Transition: `Node.setStatus(ERROR)`	Ensure atomicity and consistency of state transitions
Interaction (Interaction)	Camera, receive	Inbound Gateway: Video stream receiving port/hardware driver	Need to consider fault tolerance boundaries for high concurrency and network latency
	WeCom, administrator, send	Outbound Gateway: WeCom Webhook API Client	Need to handle retry mechanism for failed network calls

Step 3: Gap Check

✅ All data has corresponding rules for processing
✅ All interactions have corresponding rules for connection
✅ All rules have clear data operation objects
⚠️ Potential omission: Persistence storage of "alarm notifications" is not mentioned (Is historical alarm recording needed?)

Output Template

After completing the analysis, organize the output according to the following structure:

markdown

## DRI Analysis Results

### 1. Inline Annotation

> [Place the annotated original text here]

### 2. Concept Abstract Summary Table

| Abstract Dimension | Extracted Specific Concepts | System Design Mapping | Notes/Design Suggestions |
|---------|----------------|------------|-------------|
| **Data (Data)** | ... | ... | ... |
| **Rule (Rule)** | ... | ... | ... |
| **Interaction (Interaction)** | ... | ... | ... |

### 3. Gap Check

- [x] / [ ] Data Coverage Check
- [x] / [ ] Rule Coverage Check
- [x] / [ ] Interaction Coverage Check
- ⚠️ [List found omissions or redundancies]

### 4. Design Suggestions

[Architecture-level suggestions based on analysis results]

Annotation Notes

Multiple Annotations for One Word: The same word may belong to different dimensions in different contexts. For example, "temperature" alone is
```
[D:attribute]
```
, but "extract" in "extract temperature" is
```
[R:processing-action]
```
.
Granularity Control: Annotation granularity should be based on "meaningful for system modeling". Function words are not annotated.
Implicit Concepts: Pay attention to concepts implied but not explicitly stated in the text. For example, "real-time receive" implies the need for a "stream processing pipeline" or "message queue".
Domain Terms: Be sensitive to industry-specific terms, as they are often direct sources of core entities or services.

dri-text-analysis

NPX Install

Tags

SKILL.md Content (Chinese)

DRI Text Analysis Method (Data-Rule-Interaction Text Analysis)

When to Use This Skill

Core Concepts

Three-Dimensional Abstract Model

[D] Data — The "State" and "Assets" of the System

[R] Rule — The "Engine" and "Rules" of the System

[I] Interaction — The "Boundary" and "Touchpoints" of the System

[O] Other

Analysis Process

Step 1: Inline Word-by-Word Annotation

Step 2: Concept Abstract Summary Table

Step 3: Gap Check

Complete Case

Original Text

Step 1: Inline Annotation

Step 2: Concept Abstract Summary Table

Step 3: Gap Check

Output Template

Annotation Notes