Introduction

The accelerating adoption of Artificial Intelligence to support systems engineering tasks (AI4SE) puts increasing pressure on systems engineering practitioners to increase the rigor of the methodologies that they employ. Ad hoc approaches with poorly defined inputs, tasks (transformations) and outputs will yield unreliable and even dangerous results when coupled with generative AI’s predictive and non-deterministic algorithms.

This article investigates the ability of Large Language Models (LLMs) to support practitioners who use formalized requirement structure patterns as the template for analyzing originating requirements from stakeholders and transforming them into hiqh-quality natural language requirements, suitable for driving the development of solutions. As such, the article is the AI-focused follow-on to the Requirement Structure Patterns – A Comparison of Methods article that was published in PPI SyEN Edition #142 (November 2024). Two of the four patterns addressed in the first article are the subject of this analysis:

• Easy Approach to Requirements Syntax (EARS) [1,2]
• PPI Requirements Parsing Template [3]

To support this comparison, we will continue the use of the Energy Absorbing Deceleration Barrier (EADB) [4], aka Fitch Inertial Crash Barrier, as the example system and source of raw originating requirements as inputs to the LLM. This system was the subject of the Rethinking Requirements Derivation – Part 2 article in PPI SyEN Edition #130 (November 2023) in which a decision pattern was used to reverse-engineer the implicit decisions in the EADB patent application and from which an initial set of system and subsystem requirements was derived.  The focus of that article was the derivation thought process and traceability, not the precise statement of these requirements, so a subset of the 60+ requirements generated by that analysis serves well as inputs for this exercise. In addition, the entire article provides excellent context, i.e., the Why behind each requirement, for the LLM to digest when attempting to refine each requirement by use of the EARS or PPI patterns.

A second article, A Common Notation for Capturing States & Modes Requirements and Design, in PPI SyEN Edition #139 (August 2024), also used the EADB system example and produced a model of system states and modes that was also used an input to the LLM.

This article is intended investigate:

• The capabilities of an LLM to transform raw and incomplete requirements into high-quality requirements
• The differences between the effectiveness of the EARS and PPI requirement structure patterns in guiding the LLM in doing so
• How to better prompt an LLM when using its capabilities to generate structured requirement statements
• The common defects produced by the LLM when generating structured requirements
• Implications of this analysis on the engineer’s responsibility to govern AI-enabled requirements engineering

Methodology Used

Based on lessons learned during the development of PPI’s Artificial Intelligence for Systems Engineering (AI4SE) course, PPI recommends focusing on prompt engineering as the fundamental skill for leveraging AI in support of systems engineering tasks. We teach a simple 5-element prompt engineering pattern (ROTCE) [5]:

• Role
• Organizational context
• Task
• Constraints
• Evaluation

The author used this pattern, populated through a subset of eleven other prompting techniques also taught in the PPI course, to develop an initial prompt for the EARS vs PPI requirements generation exercise.  After uploading relevant documents that define the EADB system and the EARS and PPI methodologies, the author ran a 3-hour chat session with Google Gemini during which twelve raw requirements were submitted for analysis and improvement by the LLM. The free (low tier) public version of Gemini was used.  An initial attempt to use the free, low-tier version of ChatGPT failed because of its limitation of accepting only three file uploads.

The interactive chat generated a 54-page, 14,000 word output – an amazing volume of information for a 3-hour session.

Prompt Design

The full initial prompt (3-page, 750 word) in the ROTCE pattern is provided in the section that follows. Highlights of this approach include:

• Initial uploads of example system information for context and raw requirement sourcing.
• Initial uploads of EARS and PPI methodology sources for process guidance.
• Role: Act as a highly-skilled requirements analyst and systems engineer generating high-quality requirements.
• Organizational context: Simulates the scenario of developing an improved EADB starting with requirements that have been reverse engineered from an existing system.
• Task: Decomposed work to be done by the LLM into eight subtasks, generally performed on one requirement at a time, with multiple pauses after task completion to enable user feedback and iteration to correct LLM errors or “drift”.
• Constraints: Specific instructions concerning to how to complete each task, defining the format for outputs, and limiting the LLM’s ability to hallucinate new “facts” or violate the imposed methodologies.
• Evaluation: A definition of success that states the requirements quality attributes to be sought.

Requirement Structure Pattern (EARS vs PPI) Prompt

Uploads Concerning the Sample System

• Patent-US3606258-energy-absorbing-barrier-John Fitch-1971.pdf
• Rethinking Requirements Derivation – Part 2 SyEN November 2023.pdf
• A Common Notation for Capturing States+Modes Requirements and Design.pdf

Uploads Concerning Methods

• PPI Requirement Types (2 pages)
• PPI Requirements Parsing Template, Definitions and Examples (3 pages)
• EARS. https://alistairmavin.com/ears/
• The Essential Guide to Requirements Management and Traceability, Chapter 2.8 by Maven, A. Adopting the EARS Notation to Improve Requirements Engineering, published online at https://www.jamasoftware.com/legacy/requirements-management-guide/writing-requirements/adopting-the-ears-notation-to-improve-requirements-engineering/

Role:

As a highly-skilled system requirements analyst and systems engineer, use the requirement structure patterns provided (EARS and PPI Parsing Template) to successively generate high-quality system and subsystem requirements for an example system.

Organizational Context:

Your company wants to create an improved Energy Absorbing Deceleration Barrier (EADB) that provides the same capabilities as the system defined in U.S. Patent #3,606,258. Initial work has been done to reverse engineer the design decisions associated with the Fitch Inertial Barrier system that is characterized in the patent.

Task:

Classify user-entered requirements from the last two columns of Table 4-7 of the PPI SyEN paper, Rethinking Requirements Derivation – Part 2, by the requirement types defined in the EARS and PPI requirement structure templates, providing a brief rationale for that classification.

Pause for feedback and refinement of the requirement classifications.

As the classified (categorized) requirements are selectively entered by the user, improve the quality of each by requirement by rewriting it twice, using the EARS pattern first, then the PPI pattern.

Describe the rationale behind the use or non-use of each element of the requirement structure pattern.

Where necessary to resolve incompleteness or ambiguity, identify questions to be asked of stakeholders to resolve such issues.

Where needed for the sake of completeness, generate multiple requirements, that, when taken together, meet the intent of the requirement that has been entered.

Wait for feedback after generating each improved requirement.

When prompted, export a Requirements Analysis Record (RAR) table in CSV format that includes each originating requirement analyzed in this chat.

When prompted, generate a comparison between the structural elements of the EARS and PPI requirement structure patterns, highlight the top 5 commonalities and top 5 differences between these requirement models.

When prompted, generate a set of at least three recommendations for improving the prompts in this chat to improve the quality of the requirements generated from this interaction.

Constraints:

Use the two web pages uploaded at the start of this chat as the sole and immutable sources for the EARS requirements structure methodology, namely:

• EARS. https://alistairmavin.com/ears/
• The Essential Guide to Requirements Management and Traceability, Chapter 2.8 by Maven, A. Adopting the EARS Notation to Improve Requirements Engineering, published online at https://www.jamasoftware.com/legacy/requirements-management-guide/writing-requirements/adopting-the-ears-notation-to-improve-requirements-engineering/

Use the PPI Requirements Parsing Template, Definitions and Examples.pdf document uploaded at the start of this chat as the sole and immutable sources for the PPI requirements structure methodology, namely:

Limit the set of valid requirement types when classifying requirements against the EARS model to these and only these immutable values:

• Ubiquitous
• State driven
• Event driven
• Optional feature
• Unwanted behavior.

Limit the set of valid requirement types when classifying requirements against the PPI model to those types specified in the PPI Requirements Parsing Template, Definitions and Examples document.

Use the examples in the EARS and PPI sources as additional guidance for writing good requirements.

When writing improved requirements in either pattern, completely ignore the version of the requirement that has been generated against the other pattern, i.e., the EARS version must not contaminate the PPI version and vice versa.  Do not force similarity between the two results.

Use the EADB patent document and the EADB functional model and decision model in the PPI SyEN article, Rethinking Requirements Derivation – Part 2, to provide context for and inform the derivation and intent of each requirement that is entered for analysis.

When defining Preconditions and Triggers (for EARS) and Conditions for Action (for PPI) use the EABD states and modes within the document, A Common Notation for Capturing States+Modes Requirements and Design.pdf as the sole and immutable source of the EABD states, modes and state-to-state and mode-to-mode transition requirements.

State each improved requirement with the EADB system or responsible subsystem as the system name (EARS) or actor (PPI).

Format the RAR CSV file to include a comparison of:

• The verbatim originating requirement text
• The improved requirement in EARS table format
• The improved requirement in PPI table format
• Rationale for the differences between the EARS and PPI template results

Evaluation:

Focus requirement quality improvements on accuracy, completeness, clarity and verifiability of each requirement.

LLM Outputs and Analysis

Results of the interactive chat with Gemini are summarized below, along with significant lessons learned concerning LLM capabilities, effective prompting methods and the efficacy of the EARS and PPI templates.

Summary of Sample System Uploads

Although not specifically requested, Gemini provided an excellent 1.5 page summary of the EADB documents that were uploaded, including:

• System Overview (purpose, core mechanism, key design goal and impact)
• Physical and Functional Characteristics (sacrificial design, structural composition, states of operation)
• Historical and Academic Context (inventor, patent, use in systems engineering)

This pattern has been observed elsewhere in Gemini and ChatGPT, i.e., restating a context summary to “ground” the LLM on a smaller volume of deemed-to-be-essential information when compared with a much larger volume of provided system context information (40+ pages in this case).

Summary of Sample System Uploads

When prompted to categorize the raw requirements in the Rethinking Requirements Derivation article, Gemini returned just 5 requirements of the 60+ expected.  These requirements were appropriately categorized according the EARS and PPI classification scheme. However, none of the originating requirements returned matched verbatim the text of the requirements in the desired source document.

Rather than resolve this mystery (of secondary importance to the ability of the LLM to use the structure templates), the author proceeded without investigating to find and confirm root cause of this anomaly. During final review, it was discovered that a typo in the prompt requested the requirements in “Table 4-7” instead of “Tables 4-7”. This single missing character led the LLM to generate its own smaller set of requirements, likely from the EADB patent and state-model articles.

Observations and lessons learned:

• Precision in prompt inputs is of the ultimate importance. The LLM may infer correctly the user’s intent, but where ambiguity exists may substitute a shortcut (path of least resistance) and provide an anomalous output without any notification that such a shortcut was taken.
• Including an explicit constraint in the prompt to notify the user of assumptions made and shortcuts taken in the generation of outputs is a best practice that forces the LLM to justify its answers. This may also take the form of a restatement of the task to be performed and an initial inventory (manifest) of the number of objects being processed to help the user proactively detect ambiguities in the prompt or in the LLM’s interpretation of the instructions.

One-at-a-time Requirements Refinement

The core of this experiment was the submission of 12 raw requirements to the LLM for analysis and improvement by using the EARS and PPI structure templates as a guide.  The LLM accurately summarized the tasks associated with this effort as:

Once you select a requirement, I will:

1. Rewrite it using the EARS pattern.
2. Rewrite it using the PPI Parsing Template.
3. Provide the rationale for the structural elements used.
4. Identify any stakeholder questions to resolve ambiguity.

The LLM’s output faithfully followed the pattern for each requirement:

• Analysis of originating requirement
• Originating text (restated verbatim)
• EARS classification, with rationale.
• PPI classification, with rationale.
• Improved requirement: EARS pattern used, plus a table of the rewritten requirement with rationale for the pattern elements that were used
• Improved requirement: PPI pattern, plus a table of the rewritten requirement with rationale for the pattern elements that were used
• Stakeholder questions to resolve ambiguities

An opportunity for feedback was provided after each requirement was processed. On average, one additional iteration was required in this experiment to refine a requirement before moving on. In a real-world scenario with significant penalties for defective requirements, it is likely that average would rise to 3 or more iterations per requirement to achieve requirements quality sufficient to support from-scratch design of a new system of equivalent complexity.

Observations and lessons learned:

• The LLM frequently provided useful knowledge concerning relevant standards or measures of performance that might have been overlooked by inexperienced engineers. This is the most impressive of its capabilities; divergent thinking based on its access to vast volumes of training data from which the LLM can suggest potentially relevant information to consider. For example, the LLM’s ability to suggest questions to stakeholders to resolve requirement ambiguities was generally “on-point”. However, the LLM’s ability to assess the relevance of its outputs to the current context is limited; it suggests possibilities, but does not ensure a high correlation between its suggestions and the context of the problem being addressed.
• The LLM hallucinated a “Transport State” that did not exist in the source documents, despite an explicit constraint in the prompt: “When defining Preconditions and Triggers (for EARS) and Conditions for Action (for PPI) use the EADB states and modes within the document, A Common Notation for Capturing States+Modes Requirements and Design.pdf as the sole and immutable source of the EABD states, modes and state-to-state and mode-to-mode transition requirements.” LLM’s can not be trusted to reliably interpret or follow explicitly stated constraints, requiring careful review and user correction of defective outputs. Failure to detect and promptly correct such outputs may accelerate “drift” away from the clearly stated context of the chat.
• The human effort to oversee the LLM is significantly different than the effort required to guided a skilled human engineering assistant. Imprecise prompts are more likely to yield poor results than similar instructions given to human engineer who voluntarily asks questions when in doubt.
• Working with an LLM is often like playing “Whack-a-mole”. Convergence to an acceptable output often seems out of reach; settling for an 80% or 90% solution that requires human post-processing appears to be the norm.
• The PPI Parsing template includes three possible “locations” in a requirement sentence for the Constraints of Action element. The LLM used one of the two parsing examples, incorrectly inferred a rule from that example and misused that rule until corrected. Specifically, the third Constraint of Action element in several cases became a dumping ground of non-requirement “so that” (purpose) information that belongs in a Rationale attribute, not in the requirement text. Prompting the LLM to explicitly state the rules that it derives from examples may be a useful prompting practice to consider to reduce the frequency of such errors.

Differences between EARS and PPI-structured Requirements

The author was surprised at the consistent and significant differences between the requirements text generated against EARS and PPI templates. The LLM was instructed to maintain independence when processing both versions of the same originating requirement:

When writing improved requirements in either pattern, completely ignore the version of the requirement that has been generated against the other pattern, i.e., the EARS version must not contaminate the PPI version and vice versa.  Do not force similarity between the two results.

A few of the more significant examples are provided with the LLM’s rationale for the differences:

The barrier shall decelerate the vehicle

EARS: While in the Intercepting State, the EADB shall decelerate an impacting vehicle having a mass of up to 4000 lbs and a velocity of up to 60 mph at a rate not exceeding 5g.

PPI:

• [Actor: The EADB]
• [Conditions: in the Intercepting State]
• [Action: shall decelerate]
• [Object: an impacting vehicle]
• [Constraints: at a rate not exceeding 5g]
• [Refinement: having a mass of up to 4000 lbs and a velocity of up to 60 mph]
• [Constraints: until the vehicle velocity is 0 mph]

Rationale: EARS uses a ‘State Driven’ trigger to define the operational window. PPI uses the ‘Refinement of Object’ and ‘Constraints’ fields to isolate mass and velocity as distinct engineering variables for precise verification.

R.39 Prevent moisture ingress (Subsystem: Barrier Unit)

EARS: Each EADB barrier unit shall prevent the ingress of liquid water and water vapor into the dispersible mass container.

PPI:

• [Actor: Each EADB barrier unit]
• [Conditions: in the Protecting State while in Maintain Readiness Mode]
• [Action: shall prevent]
• [Object: the ingress of moisture]
• [Constraints: in accordance with IP67 standards]
• [Constraints: to maintain the dispersible mass in a free-flowing condition for the duration of its service life]

Note that the final Constraint of Action element above contains information on the purpose of the requirement that belongs in a Rationale attribute, not within the requirement text.

Rationale: EARS remains ‘Ubiquitous’ and descriptive. PPI adds the ‘Maintain Readiness Mode’ for extreme specificity and mandates a technical standard (IP67) to ensure an unambiguous verification criterion.

R.23 Fracture barrier units

EARS: When impacted by a vehicle, each EADB barrier unit shall fracture immediately to release its internal dispersible mass into the path of the vehicle.

PPI:

• [Actor: Each EADB barrier unit]
• [Conditions: in the Intercepting State while in Decelerate Vehicle Mode, upon impact by a vehicle]
• [Action: shall fracture]
• [Object: the container structure]
• [Constraints: within 50 milliseconds of contact]
• [Constraints: in a manner that exposes at least 90% of the internal dispersible mass surface area]

Rationale: EARS uses an ‘Event Driven’ trigger. PPI treats the trigger as a ‘Condition for Action’ and provides high-fidelity performance constraints (timing and surface area) to ensure the physics of the energy transfer are met.

R.32 Limit secondary hazards (flying debris)

EARS: If barrier unit fragments are generated during a vehicle impact, the EADB shall retain all fragments having a mass greater than 0.5 lbs within a 20-foot radius of the impact point.

PPI:

• [Actor: The EADB]
• [Conditions: in the Intercepting State while in Decelerate Vehicle Mode, upon impact by a vehicle]
• [Action: shall limit]
• [Object: the dispersion of fragments]
• [Constraints: such that no fragment with a kinetic energy exceeding 40 Joules travels beyond the designated safety zone]
• [Exceptions: unless the impact speed exceeds 75 mph]

Rationale: EARS utilizes the ‘Unwanted Behavior’ pattern. PPI uses the ‘Functional’ pattern with ‘Exceptions’ and quantifies the hazard using Joules (energy) rather than just mass/distance for a higher level of engineering safety assurance.

When challenged on why the LLM used different units of measurement on the flying debris, e.g., for EARS: mass + radius; for PPI: joules, the LLM’s justification was:

• The EARS methodology is designed to reduce the “noise” and complexity of natural language while remaining readable to a broad range of stakeholders.
• The PPI Parsing Template is a tool for deep engineering analysis, specifically designed to facilitate unambiguous verification and design synthesis.
• I quantified the performance differently because EARS is optimized for behavioral clarity (what the user sees), while PPI is optimized for analytical integrity (the physics the engineer must control)

The following table was provided by the LLM to compare/contrast the intent of the two patterns:

Element	EARS Pattern Justification	PPI Pattern Justification
Verification Strategy	Favors Demonstration/Inspection. You can see the debris in a 20ft circle; you can weigh a fragment.	Favors Analysis/Test. You calculate Joules to ensure the safety limit is met across all variables (mass and speed).
Structural Alignment	The System Response element is a single clause; it thrives on concise, clear physical bounds.	The Constraints of Action elements allow for multi-dimensional data (energy limits) that provide higher “fidelity.”
Intended Audience	The pattern is a “readable” bridge between users and engineers.	The template is a “parsing” tool for professional engineers to ensure no ambiguity remains.

When challenged on the traceability to the sources of these conclusions, Gemini returned:

• Evidence: The source [1] explicitly states that EARS was developed to address problems with requirements written in “unstructured natural language,” which are often “ambiguous, logically inconsistent and opaque.”
• Derivation: The methodology’s focus on five simple, natural-language patterns is described as a means to provide “low overhead” for authors and “high benefit” for those who must read them. This directly supports the assertion that the method aims to reduce “noise” (ambiguity/inconsistency) while maintaining high readability for a broad range of stakeholders who might otherwise be overwhelmed by opaque, technical jargon.
• Evidence: Mavin [2] describes the result of using EARS as “standardizing the expression” of requirements to make them “shorter and easier to understand.” He notes that the syntax is designed to be “lightweight” so it doesn’t get in the way of the engineering process.
• Derivation: The emphasis on “short,” “standardized,” and “easy to understand” expressions confirms that the primary goal is clarity and the removal of linguistic complexity (“noise”) to ensure a shared understanding across the project

The LLM’s less rigorous trace from PPI sources concludes:

• Evidence: The template breaks a single requirement into ten distinct elements, including three separate “Constraints of Action” fields, “Refinement of Object,” and “Exceptions to Action.” The “Definition of Elements” section defines Constraints (Element 4) as potentially being “performance” (how well) and separates the “Actor” from the “Conditions for Action” (Element 2).
• Derivation: This granular decomposition (parsing) is not meant for casual reading; it is a tool for “Deep Engineering Analysis.” By forcing the analyst to isolate mass from velocity or energy (as seen in the “Refinement of Object” and “Constraints” fields), the template systematically eliminates ambiguity, facilitating “unambiguous verification” and providing specific parameters for “design synthesis.”

Experienced requirement engineering practitioners of either method likely will disagree with some of these LLM conclusions, believing that individual skills and disciplined use of either approach could yield an appropriate balance of stakeholder understanding and engineering precision.

However, it is clear that the PPI parsing template encourages explicit differentiation between and inclusion of Action, Constraints of Action, Object of Action, and Refinement of Object in place of the singular System Response element in EARS. This additional granularity should significantly improve the level of requirement completeness, clarity, non-ambiguity and verifiability when applied consistently and with skill.

Gemini summarizes the commonalities and differences between EARs and the PPI parsing template, as:

Commonalities

Differences

Subject-Verb Centrality: Both models mandate a clear Actor/System Name and a specific Action/System Response, ensuring the requirement is an active statement of obligation. Conditional Logic: Both recognize that requirements are rarely universal; they provide specific slots to define States (Preconditions/Conditions) and Events (Triggers). Removal of Ambiguity: Both methodologies were explicitly developed to eliminate the “noise” and “vagueness” of unstructured natural language. Verifiability Focus: Each structure is designed to force the author to include enough detail (Constraints or Responses) to allow a tester to prove whether the requirement has been met. Standardization: Both provide a “fill-in-the-blank” syntax that ensures all requirements in a specification have a consistent look and feel, improving readability.

Granularity of Decomposition: EARS uses a “lightweight” approach with 4–5 components per pattern. PPI uses a “deep analysis” approach, parsing every requirement into 10 distinct elements. Separation of Object and Action: EARS groups the action and the object together (e.g., “shall decelerate the vehicle”). PPI separates them, allowing the vehicle to be “Refined” (e.g., mass/velocity) without complicating the verb. Handling of Exceptions: PPI provides a dedicated field for Exceptions, whereas EARS requires the author to either write a separate “Unwanted Behavior” requirement or integrate the exception into the response clause. Pattern vs. Template: EARS is Pattern-Based (selecting 1 of 5 specific syntaxes based on the requirement type). PPI is Template-Based (every requirement is processed through the same 10-element grid regardless of its type).

Conclusions

LLM’s such as Gemini and ChatGPT can offer significant value in supporting systems engineering tasks, when skillfully prompted by users with the discipline to carefully evaluate LLM outputs and correct errors and contextual drift.  Verbatim LLM outputs should never be trusted as engineering work products, but can accelerate refinement of engineering information (requirements in this context) that may be integrated with formal engineering work products.

The EARS and PPI Parsing templates provide significant advantages over ad hoc individualized requirement-authoring styles.  EARS is designed for simplicity; the PPI pattern for completeness and precision.

Further experimentation is justified to learn how movement to higher-tier (paid, team) subscriptions to the popular LLM’s might improve the quality of the requirement outputs, while minimizing user effort and “churn”.

Further engagement with the EARS and PPI communities is needed to assess whether a hybrid approach could be advantageous, i.e., developing initial requirements using EARS to support early stakeholder interactions, then leveraging the PPI parsing template as the basis for System Requirements Specifications (SyRSs) suitable to driving solution development. In such a hybrid approach the EARS pattern would be an interim entity, written as a higher-level of abstraction to gain stakeholder feedback and ultimately replaced by the more granular and specific PPI requirement in the problem baseline.

References

[1] EARS. https://alistairmavin.com/ears/

[2] Jama software, The Essential Guide to Requirements Management and Traceability, Chapter 2.8 by Maven, A. Adopting the EARS Notation to Improve Requirements Engineering, published online at https://www.jamasoftware.com/legacy/requirements-management-guide/writing-requirements/adopting-the-ears-notation-to-improve-requirements-engineering/

[3] PPI Requirements Parsing Template, embedded in PPI’s System Engineering Five-Day (SE5D) and Requirements Engineering Five-Day (RE5D) course materials.

[4] Fitch, J.C. Energy Absorbing Deceleration Barriers. U.S. Patent #3,606,258. Filed 2 January 1969. Awarded 29 September 1971.

[5] Artificial Intelligence for Systems Engineering (AI4SE), PPI course materials, 2026

About the Author

John Fitch is a Principal Consultant and Course Presenter for Project Performance International. John brings over four decades of systems engineering, engineering management, consulting and training experience to the PPI team.  In 2012, John was certified by INCOSE as an Expert Systems Engineering Professional (ESEP).

Within the field of systems engineering, John’s career has focused on decision management, requirements management, risk management, systems design & architecture, product/technology road-mapping and innovation.  In addition to defense/aerospace, John has guided initiatives in domains such as communications systems, software, energy, nanotechnology, medical devices, manufacturing systems, knowledge management and business process improvement.