dri-text-analysis

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

DRI 文本分析法 (Data-Rule-Interaction Text Analysis)

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

一种将自然语言业务需求降维拆解为系统设计基石的分析标准。本质上是在做需求工程中的领域语言（Ubiquitous Language）提取，对后续的面向对象设计、数据库建模、接口设计乃至代码脚手架生成都极具价值。

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

当用户有以下行为时使用此技能：

提供了一段业务需求描述，需要从中提炼系统的数据模型、业务规则和交互边界
说"帮我分析一下这段需求"或"把这段文字拆解成系统设计"
说"对项目进行DRI分析"或"用DRI方法解析需求文档"
想在动手写代码前，先把需求文档转化为结构化的架构抽象
需要检查需求是否存在断层（有数据没交互、有交互没规则等）
正在做领域建模，需要从自然语言中提取实体、服务、接口等概念
想把长篇需求文档拆解为可分配给不同技术组件的开发任务

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

软件系统的核心目的是：接收外部指令，处理信息，并保存状态。 DRI 模型用三个维度完整覆盖：

┌──────────────────────────────────────────────┐
│                                              │
│   触发(I) ──→ 执行(R) ──→ 读写(D)           │
│                                              │
│   反馈(I) ←── 回调(R) ←── 变化(D)           │
│                                              │
└──────────────────────────────────────────────┘

数据是体，规则是法，交互是相。

此模型与经典 ECB 模式（Entity-Control-Boundary）高度契合：

DRI 概念	ECB 模式	六边形架构	Clean Architecture
数据 (D)	Entity	Domain Model	Entities
规则 (R)	Control	Application Service	Use Cases
交互 (I)	Boundary	Port / Adapter	Interface Adapters

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) — 系统的"状态"与"资产"

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

回答 "系统里有什么"。

词性特征：名词、名词短语、特定数值、状态枚举词。
识别依据：它是否代表了系统中需要被"记住"、"存储"、"查询"或"更新"的信息？
子分类：
- 实体 (Entity)：具有唯一标识和生命周期的业务对象（如
```
监控节点
```
  、
```
画面帧
```
  ）
- 属性 (Attribute)：实体的具体特征值（如
```
温度数值
```
  、
```
运行状态
```
  ）
- 常量/配置 (Constant)：阈值、枚举值等（如
```
80度
```
  、
```
异常
```
  ）
- 流/资源 (Stream/Resource)：瞬态或持久化的数据资源（如
```
视频流
```
  、
```
现场截图
```
  ）
- 消息 (Message)：系统间传递的数据载体（如
```
报警通知
```
  ）
典型词汇：记录、数值、状态、属性、配置、快照、列表、模型、上下文

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) — 系统的"引擎"与"法则"

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

回答 "系统如何运作"。

词性特征：表示计算、判断、比较的动词，条件关联词。
识别依据：它是否定义了事物变化的条件？是否包含 If-Then 逻辑、数学运算或约束？
子分类：
- 条件判断 (Condition)：If-Then 逻辑的触发条件（如
```
如果...连续3秒超过...
```
  ）
- 阈值比较 (Threshold)：数值比较运算（如
```
超过
```
  、
```
大于
```
  、
```
等于
```
  ）
- 时间约束 (Temporal)：涉及时间窗口的判定（如
```
连续3秒
```
  、
```
每隔5分钟
```
  ）
- 领域服务 (Domain Service)：封装的复杂业务逻辑链（如
```
火灾智能推理逻辑
```
  ）
- 状态变更 (State Transition)：实体状态的转换动作（如
```
更新为异常
```
  ）
- 数据处理 (Processing)：数据转换、提取、计算（如
```
提取温度
```
  、
```
计算平均值
```
  ）
典型词汇：如果、判断、超过、匹配、计算、过滤、验证、触发、转换

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) — 系统的"边界"与"触角"

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

回答 "系统由谁触发，又影响谁"。

词性特征：表示动作转移、跨越边界的动宾短语，外部系统/物理设备的专有名词。
识别依据：它是否涉及信息的输入/输出（I/O）？是否是系统与外部世界的触点？
子分类：
- 入站 (Inbound)：外部 → 系统的数据流入（如
```
接收视频流
```
  、
```
用户点击
```
  ）
- 出站 (Outbound)：系统 → 外部的数据流出（如
```
发送通知
```
  、
```
渲染画面
```
  ）
- 外部角色 (Actor)：与系统交互的人或第三方（如
```
管理员
```
  、
```
玩家
```
  ）
- 外部设备/渠道 (Channel)：I/O 的物理或逻辑载体（如
```
摄像头
```
  、
```
企业微信
```
  、
```
API 接口
```
  ）
典型词汇：点击、接收、发送、接口、推送、显示、上传、下载、渲染

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)

[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

对原始文本逐词或逐词组进行拆解，在关键短语后紧跟方括号标签。

标注语法：

词汇[标签:子分类]

标签取值：

D:实体

D:属性

D:常量

D:流数据

D:消息

D:状态枚举

R:条件起点

R:阈值比较

R:时间约束

R:领域服务

R:状态变更

R:处理动作

I:输入设备

I:输入动作

I:输出渠道

I:输出动作

I:外部角色

I:接收端

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

将标注结果合并提炼，输出为结构化表格：

抽象维度	提取出的具体概念	系统设计映射	备注/设计建议
数据 (Data)	从标注中提取的所有 D 标签内容	领域模型/实体、配置项、持久化表设计	瞬态 vs 持久化、可配置 vs 硬编码
规则 (Rule)	从标注中提取的所有 R 标签内容	核心算法、领域服务、状态机	需重点编写单元测试的部分
交互 (Interaction)	从标注中提取的所有 I 标签内容	入站网关、出站网关、UI 组件	容错、重试、并发处理

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

完成表格后执行 D-R-I 交叉验证：

数据无交互：存在数据但没有任何交互去创建/修改/读取它 → 需求可能遗漏了输入输出。
交互无规则：存在交互（如接收数据）但没有规则去处理 → 需求可能遗漏了业务逻辑。
规则无数据：存在规则但没有操作的目标数据 → 规则可能是冗余的或数据定义缺失。
孤立实体：某个数据实体既不被规则引用，也不通过交互暴露 → 可能是过度设计。

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

"监控系统通过摄像头实时接收视频流，提取当前画面帧的温度数值。如果温度连续3秒超过80度，则触发火灾智能推理逻辑，系统自动通过企业微信向管理员发送包含现场截图的报警通知，并在数据库中将该监控节点的运行状态更新为异常。"

"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

监控系统
[I:接收端]
通过摄像头
[I:输入设备]
实时接收
[I:输入动作]
视频流
[D:流数据]
，提取
[R:处理动作]
当前画面帧
[D:实体]
的温度数值
[D:属性]
。如果
[R:条件起点]
温度
[D:属性]
连续3秒
[R:时间约束]
超过
[R:阈值比较]
80度
[D:常量]
，则触发
[R:状态变更]
火灾智能推理逻辑
[R:领域服务]
，系统自动通过企业微信
[I:输出渠道]
向管理员
[I:外部角色]
发送
[I:输出动作]
包含现场截图
[D:流数据]
的报警通知
[D:消息]
，并在数据库中将该监控节点
[D:实体]
的运行状态
[D:属性]
更新为
[R:状态变更]
异常
[D:状态枚举]
。

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

抽象维度	提取出的具体概念	系统设计映射	备注/设计建议
数据 (Data)	视频流、画面帧、温度数值	领域模型： `VideoFrame` , `Temperature`	视频流属于瞬态内存数据，画面帧可能需要缓存
	80度（阈值常量）	配置项： `ALARM_TEMP_THRESHOLD = 80`	应设计为可配置参数，而非硬编码
	报警通知、现场截图	消息/资源： `AlarmMessage` , `ImageResource`	截图需持久化至对象存储，通知记入日志
	监控节点、运行状态、异常	持久化实体： `MonitorNode (Status: Normal/Error)`	对应数据库中的节点表及状态枚举字段
规则 (Rule)	提取（温度）	数据处理：图像识别/传感器数据解析算法	将非结构化数据转化为结构化数据
	如果...连续3秒超过...	推理引擎/状态机：时序数据滑动窗口判断	核心业务规则，需重点编写单元测试防误报
	触发火灾智能推理逻辑	领域服务： `FireReasoningService`	封装复杂的判定链条
	更新为（异常状态）	状态变更： `Node.setStatus(ERROR)`	确保状态变更的原子性和一致性
交互 (Interaction)	摄像头、接收	入站网关：视频流接收端口/硬件驱动	需考虑高并发与网络延迟的容错边界
	企业微信、管理员、发送	出站网关：企业微信 Webhook API 客户端	需处理网络调用失败的重试机制

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

分析完成后，按以下结构组织输出：

markdown

undefined

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

markdown

undefined

DRI 分析结果

DRI Analysis Results

一、行内标注

1. Inline Annotation

[在此放置标注后的原始文本]

[Place the annotated original text here]

二、概念抽象汇总表

2. Concept Abstract Summary Table

抽象维度	提取出的具体概念	系统设计映射	备注/设计建议
数据 (Data)	...	...	...
规则 (Rule)	...	...	...
交互 (Interaction)	...	...	...

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

三、断层检查

3. Gap Check

/ [ ] 数据覆盖检查
/ [ ] 规则覆盖检查
/ [ ] 交互覆盖检查
⚠️ [列出发现的遗漏或冗余]

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

四、设计建议

4. Design Suggestions

[基于分析结果给出的架构层面建议]

undefined

[Architecture-level suggestions based on analysis results]

undefined

标注注意事项

Annotation Notes

一词多标：同一个词在不同上下文中可能属于不同维度。如"温度"单独出现时是
```
[D:属性]
```
，但"提取温度"中的"提取"是
```
[R:处理动作]
```
。
粒度把控：标注粒度以"对系统建模有意义"为准。虚词不标注。
隐含概念：注意文本中未明确说出但暗示的概念。如"实时接收"暗示了需要"流处理管道"或"消息队列"。
领域术语：对行业特有术语保持敏感，它们往往是核心实体或服务的直接来源。

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.