Keyword-Driven Test Specifications for Nontechnical Requirements

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing programming languages like TTCN require significant time to learn and are unintelligible to non-technical users, hindering efficient test automation and specification processes.

Innovation Solution

A keyword-driven approach using phrases that combine established syntax rules with evolving semantics, allowing users to create test specifications and requirements without extensive training, supported by a customizable vocabulary and tooling that facilitates easy translation and automation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If standardized programming languages like TTCN are used for test specification, then testing precision and automation capability are improved, but learning time and operational difficulty increase significantly

Engineering Contradiction:
Improvetesting precisionVSAvoidlearning time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent introduces an intermediary layer between natural language requirements and formal test specifications. This intermediary consists of domain-specific phrases and templates that automatically translate business requirements into structured test cases, eliminating the need for users to learn complex programming languages while maintaining testing precision.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates reusable templates and phrase libraries that can be copied and adapted for different test scenarios. These templates encapsulate common testing patterns and syntax rules, allowing users to generate formal test specifications by filling in template parameters rather than writing complete test logic from scratch.

Inventive Principle:
Principle #26Copying

2Extent of automation

If formal programming languages are used for test specification, then automation capability is improved, but ease of operation deteriorates for non-technical users

Engineering Contradiction:
Improveautomation capabilityVSAvoidease of operation
Core Design Contradiction:
Extent of automationVSEase of operation

Solution Approach 1:

The patent segments the test specification process into distinct, manageable components: natural language requirements, domain-specific phrases, template structures, and automated generation rules. This segmentation allows non-technical users to work with familiar language while the system handles the complex automation logic through predefined segments.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary layer between natural language requirements and formal test specifications. This intermediary consists of domain-specific phrases and templates that automatically translate business requirements into structured test cases, eliminating the need for users to learn complex programming languages while maintaining testing precision.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If comprehensive keyword vocabularies are created for keyword-driven testing, then adaptability and coverage are improved, but device complexity and maintenance effort increase

Engineering Contradiction:
ImproveadaptabilityVSAvoidvocabulary complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal phrase library where each phrase is designed to serve multiple testing scenarios and domains. Rather than creating separate vocabularies for different test types, the same set of phrases can be applied across various testing contexts, reducing overall vocabulary complexity while maintaining broad adaptability.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent implements a dynamic vocabulary system where phrases and templates can be easily added, modified, or removed based on evolving testing requirements. This dynamic structure allows the vocabulary to adapt to new domains and test scenarios without requiring complete restructuring, maintaining low complexity while high adaptability.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP3608785B1Keyword-driven requirements
Publication Date: 2026.02.18 PIRO SYST ENG GMBH
  • EP3608785B1 patent drawingFigure 1
  • EP3608785B1 patent drawingFigure 2

AI summary

Problem One disadvantage in the use of languages such as TTCN is the length of time required to learn them. Also, many nontechnical users find them unintelligible. Solution Computer-implemented method (10) comprising defining requirements (11) for a system under test, transforming the requirements (11) into functional specifications (12) using documented keywords, and, driven by the keywords, generating test cases (16) for the system, characterized in that the requirements (11) are defined through phrases containing the keywords.