From Zero to One: Building an AI Requirement Analysis Engine – Full Technical Walkthrough of the Skills Architecture

1. Why Requirement Analysis Becomes a Bottleneck in Development

In many mid‑to‑large teams, requirement analysis appears to be the product manager's job, but it is actually the starting point of the entire delivery pipeline. Instability at this stage propagates to system design, interface development, integration testing, and release acceptance.

For a SaaS platform handling instant messaging, project collaboration, document management, approval flows, and permission centers, the quarterly active demand exceeds hundreds. The real problem is not "slow development" but "different people think they understand the same requirement while they actually do not".

Product managers describe goals in business language, while engineers need system boundaries, state machines, and exception branches.

A seemingly simple feature often touches multiple services, roles, and approval chains.

Experienced teammates can infer hidden rules; newcomers must rely on meeting minutes and chat logs.

Review meetings become longer, but logical conflicts often surface only in later development stages.

These issues stem from the lack of a middle layer that translates "vague requirements" into "engineered objects".

2. Requirement‑Analysis Engine Is Not a Chatbot

Typical attempts use a chat interface where a product manager inputs a sentence and the model returns a PRD‑like description. Demos look good, but they fail in real development because:

Outputs are unstable; the same request yields different structures and boundaries.

The model hallucinates non‑existent business rules, fields, and APIs.

The result cannot be fed directly into review, design, development, or testing stages.

When demand scales, request cost, latency, and error rates explode.

Enter the Skills Engine : a verifiable, versioned, and auditable capability unit that turns requirement analysis into a production‑ready pipeline.

3. Core Engineering Questions

What role does Skills play in the requirement‑analysis scenario?

Why is it more suitable than a plain chat, RAG, or workflow node as a capability base?

How to transform raw requirements into structured cards, interface changes, and risk lists?

How to keep the system stable and scalable under high concurrency, multi‑tenant, and complex business rules?

How to integrate the system into real development workflows instead of staying in a demo environment?

4. Why Ordinary LLMs Fail at Requirement Analysis

Three fatal problems:

LLMs excel at completion but requirement analysis fears "fabrication". For example, when a user asks for "add approval capability", the model may invent approval persons, copy‑recipients, timeout reminders, and rollback rules that do not exist.

LLMs lack internal anchors to a company's domain knowledge (RBAC vs. ABAC, order state reversibility, cross‑department approvals, historical compatibility constraints).

The output is uncontrolled and cannot enter an engineering pipeline; natural‑language answers, however beautiful, cannot be reliably transformed into structured objects.

5. Skills as a Governable "Requirement‑Analysis Module"

Skills are not just better prompts; they are versioned, auditable capability units that must answer six questions:

What problem does the skill solve?

What triggers the skill?

Which knowledge, rules, scripts, and tools does it depend on?

What are the input and output schemas?

How are errors recovered and boundaries enforced?

How are evaluation and regression cases organized?

Each skill includes: SKILL.md: purpose, trigger, steps, boundaries. schemas/: input/output definitions. prompts/: system instructions, few‑shot examples, constraint templates. resources/: domain knowledge, workflow rules, API catalog. scripts/: data normalization and post‑processing. policies/: permission limits, budget, manual‑review rules. evals/: regression cases to guarantee no degradation on upgrades.

6. The End‑to‑End Compilation Pipeline (Seven Stages)

Stage 1 – Input Normalization

Raw input may be meeting minutes, Jira/TAPD titles, prototype links, customer tickets, or historical change logs. Normalization removes noise, extracts key entities, identifies modules, roles, and business objects, and creates a unified RequirementDraft object.

Stage 2 – Intent Classification & Slot Extraction

The goal is not to generate a full PRD but to answer:

Is this a new feature, rule change, workflow modification, or compatibility fix?

Which business objects and roles are involved?

Does it affect read flow, write flow, or state transition?

Which constraints are already clear and which are missing?

A lightweight model handles high‑throughput frequent intents; a heavyweight model fills in ambiguous cases.

Stage 3 – Knowledge Retrieval & Constraint Injection

Instead of dumping all knowledge into the model, the system loads only what is needed based on intent and slots:

OpenAPI definitions of related services.

Table schemas and field semantics.

State‑machine and approval rules.

Permission matrices.

Historical similar requirement cards.

Retrieval uses a hybrid of vector search, graph lookup, and rule lookup.

Stage 4 – Structured Requirement Compilation

The model output is compiled into a JSON RequirementCard such as:

{
  "requirementId": "REQ-20260727-1024",
  "module": "TASK_CENTER",
  "intent": "WORKFLOW_RULE_CHANGE",
  "actors": ["PROJECT_ADMIN", "TASK_OWNER"],
  "businessObjects": ["TASK", "APPROVAL_FLOW"],
  "preconditions": ["task.status in [DRAFT, PENDING_APPROVAL]"],
  "mainFlow": ["任务创建后可绑定审批模板", "审批通过后任务状态变为 ACTIVE"],
  "exceptionFlows": ["审批拒绝后任务状态回退到 DRAFT"],
  "nonFunctionalRequirements": {"audit": true, "latencyP95Ms": 300, "idempotent": true},
  "impactedApis": [],
  "risks": [],
  "openQuestions": [],
  "knowledgeVersion": "v2023.07"
}

Stage 5 – Conflict Detection

Beyond simple text similarity, the engine checks concrete rule and state conflicts, e.g.:

Whether two roles are granted mutually exclusive permissions.

Whether a state transition becomes unreachable or creates a dead‑loop.

Whether an approval chain violates organizational segregation.

Whether a new field conflicts with existing API compatibility policies.

Stage 6 – Impact Analysis

The card is mapped to engineering artifacts:

List of affected services (e.g., task-service, approval-service, audit-service).

Database tables and fields to be changed.

Front‑end pages and instrumentation that need updates.

Event streams and monitoring hooks.

Stage 7 – Artifact Delivery

Structured outputs are pushed directly to downstream tools:

Generate a review card for product managers.

Sync to Jira/TAPD.

Create OpenAPI change drafts.

Generate test scenarios and acceptance checklists.

Provide task‑breakdown suggestions for developers.

7. Real‑World Business Case: Approval Flow in a Task Center

A product manager proposes: "Add an approval flow where tasks with a budget > 50 k require project‑owner approval; approved tasks move to IN_PROGRESS, rejected tasks revert to DRAFT, and audit logs must be kept." The engine processes it as follows:

Intent identification: module = TASK_CENTER, intent = WORKFLOW_RULE_CHANGE, actors = PROJECT_MEMBER / PROJECT_OWNER, objects = TASK, APPROVAL_FLOW, BUDGET.

Domain knowledge retrieval: task state‑machine, budget field definition, existing approval service APIs, permission for PROJECT_OWNER, audit compliance.

Structured card generation: (JSON shown above).

Conflict checks: verify state‑machine path DRAFT → PENDING_APPROVAL → IN_PROGRESS exists, confirm PROJECT_OWNER has approval permission, ensure audit covers budget changes.

Impact output: affected services = task-service, approval-service, audit-service; front‑end task creation page and status UI need updates; new event task_approval_created added.

This structured output eliminates the manual translation step from a narrative PRD to engineering artifacts.

8. Production‑Grade Engineering: High Concurrency, Multi‑Tenant, Scalability

8.1 Concurrency Governance

Not every request needs the strongest model. Requests are tiered:

L1 – Clear, template‑driven demands handled by lightweight models.

L2 – Cross‑module dependencies handled by medium models.

L3 – Highly ambiguous, cross‑domain, multi‑constraint demands handled by heavyweight models.

Queue‑based spike‑shaving and token‑budget control prevent prompt explosion.

8.2 Multi‑Tenant Isolation

Knowledge indexes are partitioned per tenant.

Historical cards are stored in tenant‑scoped spaces.

Context building filters by tenant boundaries.

All logs, audits, and exports carry tenant identifiers.

Sensitive fields are masked before logging.

8.3 Extensibility via Skills

Future skills may cover data‑report analysis, permission changes, billing rule updates, workflow configuration, multimodal prototype analysis, etc. Without a Skill Registry and unified I/O contracts, these would devolve back into ad‑hoc prompts.

9. Stability Practices for an Deployable AI System

9.1 Rate‑Limiting, Circuit‑Breaker, Degradation

Gateway‑level tenant, API, and user throttling.

Model‑service failure thresholds trigger circuit‑breakers.

Fallback to local models or lightweight paths when strong models are unavailable.

Graph service fallback to pure vector search + rule base.

9.2 Idempotency & Retry

Idempotent key = tenantId + sourceId + sourceVersion. Only timeout, 429, or transient network errors are auto‑retried; write‑side operations must be deduplicated.

9.3 Observability

System metrics: QPS, P95/P99 latency, model error/timeout rates, vector‑search latency, Kafka lag. Quality metrics: intent‑classification accuracy, schema‑validation failure rate, conflict false‑positive/negative rates, manual‑revision ratio, API‑derivation hit rate.

10. Integration into Real Development Workflows

Requirement entry: product managers submit via portal, Jira/TAPD plugin, or IDE plugin; an analysis task is created automatically.

Initial structuring: Skills engine outputs a structured card, open questions, risks, and impact scope.

Human confirmation: only ambiguous parts are reviewed, not the whole PRD.

Technical review: engineers review the structured card instead of raw text.

Automatic artifact generation: interface change suggestions, test scenario drafts, task‑breakdown recommendations, audit checks.

Post‑release feedback: real change results, defects, and rollbacks are fed back into the evaluation set for continuous Skill improvement.

The closed‑loop looks like: Requirement → AI Structured Analysis → Human Confirmation → Engineering Execution → Release Feedback → Evaluation → Skill Optimization.

11. Deployment Practices (Cloud‑Native)

11.1 Container Image

FROM eclipse-temurin:21-jre-alpine
WORKDIR /app
COPY target/requirement-analysis-engine.jar app.jar
ENTRYPOINT ["java", "-XX:+UseZGC", "-XX:MaxRAMPercentage=75", "-jar", "/app/app.jar"]

11.2 Kubernetes Manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: requirement-analysis-engine
spec:
  replicas: 4
  selector:
    matchLabels:
      app: requirement-analysis-engine
  template:
    metadata:
      labels:
        app: requirement-analysis-engine
    spec:
      containers:
      - name: engine
        image: registry.example.com/ai/requirement-analysis-engine:1.0.0
        ports:
        - containerPort: 8080
        env:
        - name: MODEL_ROUTER_ENDPOINT
          value: "http://model-router.default.svc.cluster.local"
        - name: KAFKA_BOOTSTRAP_SERVERS
          value: "kafka.default.svc.cluster.local:9092"
        resources:
          requests:
            cpu: "2"
            memory: "4Gi"
          limits:
            cpu: "4"
            memory: "8Gi"
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: requirement-analysis-engine
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: requirement-analysis-engine
  minReplicas: 4
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

11.3 Production Recommendations

Separate sync API from async workers.

Isolate model routing as an independent service.

Cache hot knowledge snippets to reduce vector‑store pressure.

Make Skill and knowledge versions traceable for quick rollbacks.

12. Common Pitfalls

Treating Skill as a mere prompt repository without schema, evaluation, versioning, and governance leads to decay.

Relying only on RAG without a compilation step leaves the output as unstructured text.

Ignoring knowledge freshness; API or schema changes quickly pollute analysis results.

Missing human‑validation checkpoints for high‑risk scenarios (permissions, billing, compliance).

Testing only system performance while ignoring result quality; frequent manual rewrites nullify the value.

13. Evolution Roadmap: From 0→1 to 1→N

Phase 1 – Minimal Viable Product: focus on a high‑frequency module, support a few clear intents, output structured cards, rely on manual downstream review.

Phase 2 – Asset Integration: connect to API docs, schemas, rule bases, historical cards; add conflict detection and impact analysis; integrate with Jira/TAPD.

Phase 3 – Production Governance: introduce Skill Registry, evaluation suite, model routing, queue spike‑shaving, observability, multi‑tenant isolation, gray‑release and rollback mechanisms.

Phase 4 – Closed‑Loop Intelligence: auto‑generate test scenarios, OpenAPI drafts, task breakdowns; feed back production results and defects to continuously improve Skills; expand to multimodal inputs (prototypes, recordings).

14. Conclusion

Using AI merely to "polish a PRD" improves expression efficiency but does not change the development bottleneck. By treating Skills as the foundational infrastructure for requirement analysis, the process becomes a verifiable, governable, and replayable engineering pipeline. It answers critical questions such as how to translate vague requirements into consumable objects, how to safely inject enterprise knowledge, how to expose conflicts and impact automatically, and how to remain stable and cost‑effective at scale. This shift—from a chat window to a full‑stack Skills‑based system—is the most valuable direction for AI‑augmented requirement analysis.