TL;DR
Ask a model to "extract all the requirements from this document" and it fixates on the obvious and misses what's hidden. PEGS prompting fixes this structurally: instead of one general request, you give it four specific angles of analysis — Project, Environment, Goals, System. The model doesn't guess what to look for; it walks through the given categories one by one.
The main finding: models tend to "lock onto" the obvious requirements and cluster in one zone. With a general "extract the requirements" request, ~60% of the categories in the document go uncovered. The model focuses on explicit technical specs and ignores context (who the client is, what external constraints exist, what goals sit behind the task).
PEGS prompting switches the model from "look for things that resemble a requirement" mode to "walk through four clear dimensions" mode. Each dimension is a separate, narrowly targeted request with a clear semantic boundary. Category coverage climbs from 61% to 92% — practically no blind spots left.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
Works in a single prompt with four lens sections:
LENS 1: Project (P) → stakeholders, budget, timeline, organizational context
LENS 2: Environment (E) → external systems, regulatory requirements, operating conditions
LENS 3: Goals (G) → business goals, success criteria, user expectations
LENS 4: System (S) → functional requirements, non-functional ones (speed, security, reliability)
Each lens gives the model a concrete search target. Not "find everything", but "find this specific thing".
Example in Practice
Task: A freelancer gets a brief from a client — a startup wants to launch a service for managing employee business travel. The document is 4 pages long and written all over the place. You need to figure out what you're actually supposed to build.
Prompt:
Here is a client brief. Analyze it across four categories — go through each one separately
and don't move on to the next until you've finished the current one.
CATEGORY P — PROJECT:
Who is the client and what kind of company is it? Who are the users? What are the constraints: budget, timeline,
team? What organizational factors need to be considered?
CATEGORY E — ENVIRONMENT:
Which external systems need integration (accounting, flight booking, banks)?
What regulatory or legal requirements are mentioned? What operating conditions
(mobile devices, offline mode)?
CATEGORY G — GOALS:
What business goals are behind the product? What counts as success? What does
the user ultimately want to get? What pain points are we solving?
CATEGORY S — SYSTEM:
What exactly must the system do (features)? What are the non-functional requirements
(speed, security, scale, reliability)?
In each category: list your findings. After all four, point out which
requirements overlap or contradict each other.
BRIEF:
[paste the brief text]
Result: The model will go through all four sections in order, each with a structured list. Section G will surface things the brief never states explicitly — the model will infer them from context. Section E will catch integrations and constraints the client never named outright. At the end you get a list of contradictions to clarify on a call. One chaotic document turns into a four-block structure that's ready for estimating.
Why It Works
The model's weakness: an LLM generates text along the most probable pattern. Ask it to "find the requirements" and it produces what looks like typical requirements: explicit technical specs. Implicit constraints, business context, external dependencies look different, and the model doesn't "see" them as requirements.
The model's strength: on the other hand, it works well with a tightly bounded search space. When the prompt says "look only at regulatory and operational constraints", the model literally narrows its search and finds what was drowning under the broad request.
How the method uses this: PEGS turns one complex, fuzzy request into four narrow, targeted ones. Each category is its own context with clear examples of what belongs there. The model doesn't guess — it follows a route.
Control levers: - Add examples inside a category — after the category name write "for example: response-time requirement, load requirement". This gives the model a pattern to work from - Add a "Risks" category — the four PEGS categories can be extended with a fifth one for your task - Change the output format — instead of a list, ask for a table with columns "Requirement / Priority / Source in the document" - Add a conflict check — "after all the categories, list the contradictions" — that's built-in verification
Prompt Template
Analyze the {document/text/brief} across four categories.
Go through each category separately and completely before moving on to the next.
CATEGORY P — PROJECT:
Who is involved? What organizational constraints exist (timeline, budget, team)?
What context matters for understanding the task?
CATEGORY E — ENVIRONMENT:
Which external systems, services, tools are involved or mentioned?
What regulatory, legal or operational constraints are there?
CATEGORY G — GOALS:
What business goals are behind the task? What counts as success?
What should the user or client ultimately get?
CATEGORY S — SYSTEM:
What specifically must it do (features)?
What non-functional requirements: speed, security, reliability, scale?
For each category: {format — list / table / paragraphs}.
At the end: point out overlaps and contradictions between categories.
{document/text}
Placeholders:
- {document/text/brief} → what we're analyzing: a spec, a contract, a project description, a client email
- {format} → how to present the result: list, table, numbering
🚀 Quick start — paste into the chat:
Here is a PEGS prompting template. Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what to analyze and what format you need the result in — because the method adapts to any document type and any desired output format. It will take the four-category structure and tune it to your task.
Limitations
⚠️ Short, simple texts: For a one-paragraph email or a simple request, PEGS is overkill — some categories will come out empty. The method shines on long, multi-part documents.
⚠️ The "Environment" category is the hardest: External constraints and regulatory context are often written as background text rather than explicit requirements. The model misses them more often than other categories — even with PEGS. It's worth running this section through a separate follow-up request.
⚠️ Implicit requirements via references: If the document references another standard or document ("must comply with ISO/IEC 27001"), the model doesn't know that document's contents and won't pull out the requirements hidden there.
⚠️ The method is built for documents: It works well for analyzing texts. For creative, subjective or open-ended tasks, the four-category structure doesn't fit.
Resources
Paper: ReqFusion: A Multi-Provider Framework for Automated PEGS Analysis Across Software Domains
PEGS methodology: Bertrand Meyer, the original Project-Environment-Goals-System framework
Authors: Muhammad Khalid, Manuel Oriol, Yilmaz Uygun — Constructor University Bremen, Germany
System demo: https://re-engineer-app-khalid.replit.app