Core Concepts
Requirements
How AI changes requirements
In traditional development, vague requirements are resolved through back-and-forth with engineers. In AI-driven development, ambiguity forces the system to either make assumptions or stop.
Because Morph builds autonomously, requirements act as the primary control surface. The system can only act on what is explicitly defined. Ambiguity compounds as work progresses.
As a result:
Requirements define constraints, not just features
Production criteria are established early
Unclear requirements propagate across system design and implementation
Clear requirements enable predictable builds. Vague requirements introduce rework.
What requirements define
Requirements specify:
Intent
the problem being solved
the users and their goals
Behavior
workflows that must be supported
success conditions for each workflow
business rules and validation logic
error handling and edge cases
Structure
data relationships and constraints
integration touchpoints with existing systems
Constraints
security and access control
performance expectations
compliance or regulatory needs
technology or infrastructure boundaries
Tradeoffs
features prioritized vs deferred
scope limitationscomplexity boundaries
Each requirement narrows the solution space and guides downstream decisions.
What to include in requirements
1. User actions (not just features)
The system needs to understand workflows, not just capabilities.
Inadequate | Effective |
User authentication, file upload, notifications | Sales reps log in with email/password, upload signed contracts (PDF only, max 10MB), and receive email notification when the contract is processed. Managers can view all contracts for their team; reps only see their own. |
Why the difference matters:
Inadequate: Lists capabilities with no context on who, when, or how. The system can't determine access controls, file constraints, or notification triggers.
Effective: Defines user roles, authentication method, file type and size limits, workflow triggers, and permission boundaries. System has complete context to build the feature correctly.
2. Business rules and edge cases
Don't make the system guess how your business logic works.
Inadequate | Effective |
Track inventory levels | Track inventory by SKU. Alert warehouse manager when quantity drops below 50 units OR 2-week average sales volume (whichever is higher). Only warehouse managers can override low-stock alerts. Users cannot create orders that would result in negative inventory. |
Why the difference matters:
Inadequate: States what to track but not the business logic, thresholds, or constraints. System doesn't know when to alert, who can override, or how to handle edge cases.
Effective: Specifies alert thresholds with conditional logic, role-based permissions for overrides, and explicit constraint on negative inventory. System can implement complete business rules.
3. Data relationships with real-world context
Explain why relationships exist, not just that they do.
Inadequate | Effective |
Customers have many orders | Each customer can place multiple orders. Orders are tied to the billing contact on file at order time (not updated if billing contact changes later). Customer service reps need to see full order history when resolving disputes. |
Why the difference matters:
Inadequate: States the relationship but not the business logic or workflow needs. System doesn't know when to capture billing contact or how to handle changes.
Effective: Explains when data snapshots happen, how updates are handled, and why the relationship matters for user workflows. System can make correct architectural decisions about data integrity.
4. Integration requirements with intent
Specify what needs to happen across system boundaries.
Inadequate | Effective |
Integrate with Stripe | Process payments via Stripe. Customers should be able to save payment methods for future use. Failed payments should trigger email notification to customer and internal alert to billing team. |
Why the difference matters:
Inadequate: Names the integration but provides no detail on what needs to happen, when, or how failures are handled.
Effective: Specifies payment workflows, saved payment methods, error handling with notifications. System knows what to build and how to handle failure scenarios.
5. Production signals, not prototype assumptions
Include details that separate working software from prototypes.
Validation: What data is required vs. optional? What formats are acceptable?
Authentication: Who can access what? How should sessions be managed?
Error handling: What happens when external APIs fail? How should users be notified?
Performance: Are there response time requirements? Data volume constraints?
Common mistakes
1. Goal-only requirements
Stating what you want without describing how it should work leaves the system without actionable constraints.
2. Implementation details without business context
Specifying technologies or architectures without explaining why blocks the system from making appropriate tradeoffs.
3. Implicit business rules
Rules that exist in your head but aren't documented become assumptions the system makes incorrectly or blocks on.
4. Missing production details
Prototypes skip validation, error handling, and edge cases. Production apps can't. If these aren't in requirements, they won't be in the build.
5. Feature lists without integration context
Capabilities that need to work together must be specified with their relationships and data flows, not as isolated features.
How requirements flow through Morph
The feedback loop:
System design surfaces implications of your requirements. When you review the architecture, you may discover:
Constraints that need clarification
Tradeoffs worth reconsidering
Edge cases you hadn't thought through
This is expected. Adding clarifications or additional requirements after seeing system design is normal. It's the system helping you think through decisions before implementation begins.
Why this matters:
Once implementation begins, requirements are locked in as build inputs. Changes after implementation starts trigger rework across affected components. The earlier you add clarifications and address gaps, the less expensive iteration becomes.
Production-ready from requirements
Morph's outcome-based pricing means you only pay for working software. "Working" is defined by your requirements.
This means requirements need to specify:
Validation criteria. What makes a workflow complete vs. incomplete?
Error conditions. What happens when things fail?
Access control. Who can do what?
Data integrity. What constraints must be enforced?
Integration behavior. How should external system failures be handled?
The more precise your requirements, the less ambiguity about what "working" means when validating the final application.
When you're uncertain
You don't need to be technical. Requirements should focus on business logic and user intent, not implementation details.
You don't need to be exhaustive. It's better to deeply specify 3 critical workflows than vaguely describe 10.
You don't need to be perfect upfront. System design will reveal gaps and ambiguities. That's the point of the phased approach.
What you do need: Clarity about what success looks like for the users and workflows you're prioritizing.
Related documentation
Requirements & System Overview - See how structured requirements translate into an actionable system architecture and implementation plan
System Design — How Morph translates requirements into technical architecture
Quick Start Guide — A fast overview to get started with your first Morph project
In traditional development, vague requirements are resolved through back-and-forth with engineers. In AI-driven development, ambiguity forces the system to either make assumptions or stop.
Because Morph builds autonomously, requirements act as the primary control surface. The system can only act on what is explicitly defined. Ambiguity compounds as work progresses.
As a result:
Requirements define constraints, not just features
Production criteria are established early
Unclear requirements propagate across system design and implementation
Clear requirements enable predictable builds. Vague requirements introduce rework.
What requirements define
Requirements specify:
Intent
the problem being solved
the users and their goals
Behavior
workflows that must be supported
success conditions for each workflow
business rules and validation logic
error handling and edge cases
Structure
data relationships and constraints
integration touchpoints with existing systems
Constraints
security and access control
performance expectations
compliance or regulatory needs
technology or infrastructure boundaries
Tradeoffs
features prioritized vs deferred
scope limitationscomplexity boundaries
Each requirement narrows the solution space and guides downstream decisions.
What to include in requirements
1. User actions (not just features)
The system needs to understand workflows, not just capabilities.
Inadequate | Effective |
User authentication, file upload, notifications | Sales reps log in with email/password, upload signed contracts (PDF only, max 10MB), and receive email notification when the contract is processed. Managers can view all contracts for their team; reps only see their own. |
Why the difference matters:
Inadequate: Lists capabilities with no context on who, when, or how. The system can't determine access controls, file constraints, or notification triggers.
Effective: Defines user roles, authentication method, file type and size limits, workflow triggers, and permission boundaries. System has complete context to build the feature correctly.
2. Business rules and edge cases
Don't make the system guess how your business logic works.
Inadequate | Effective |
Track inventory levels | Track inventory by SKU. Alert warehouse manager when quantity drops below 50 units OR 2-week average sales volume (whichever is higher). Only warehouse managers can override low-stock alerts. Users cannot create orders that would result in negative inventory. |
Why the difference matters:
Inadequate: States what to track but not the business logic, thresholds, or constraints. System doesn't know when to alert, who can override, or how to handle edge cases.
Effective: Specifies alert thresholds with conditional logic, role-based permissions for overrides, and explicit constraint on negative inventory. System can implement complete business rules.
3. Data relationships with real-world context
Explain why relationships exist, not just that they do.
Inadequate | Effective |
Customers have many orders | Each customer can place multiple orders. Orders are tied to the billing contact on file at order time (not updated if billing contact changes later). Customer service reps need to see full order history when resolving disputes. |
Why the difference matters:
Inadequate: States the relationship but not the business logic or workflow needs. System doesn't know when to capture billing contact or how to handle changes.
Effective: Explains when data snapshots happen, how updates are handled, and why the relationship matters for user workflows. System can make correct architectural decisions about data integrity.
4. Integration requirements with intent
Specify what needs to happen across system boundaries.
Inadequate | Effective |
Integrate with Stripe | Process payments via Stripe. Customers should be able to save payment methods for future use. Failed payments should trigger email notification to customer and internal alert to billing team. |
Why the difference matters:
Inadequate: Names the integration but provides no detail on what needs to happen, when, or how failures are handled.
Effective: Specifies payment workflows, saved payment methods, error handling with notifications. System knows what to build and how to handle failure scenarios.
5. Production signals, not prototype assumptions
Include details that separate working software from prototypes.
Validation: What data is required vs. optional? What formats are acceptable?
Authentication: Who can access what? How should sessions be managed?
Error handling: What happens when external APIs fail? How should users be notified?
Performance: Are there response time requirements? Data volume constraints?
Common mistakes
1. Goal-only requirements
Stating what you want without describing how it should work leaves the system without actionable constraints.
2. Implementation details without business context
Specifying technologies or architectures without explaining why blocks the system from making appropriate tradeoffs.
3. Implicit business rules
Rules that exist in your head but aren't documented become assumptions the system makes incorrectly or blocks on.
4. Missing production details
Prototypes skip validation, error handling, and edge cases. Production apps can't. If these aren't in requirements, they won't be in the build.
5. Feature lists without integration context
Capabilities that need to work together must be specified with their relationships and data flows, not as isolated features.
How requirements flow through Morph
The feedback loop:
System design surfaces implications of your requirements. When you review the architecture, you may discover:
Constraints that need clarification
Tradeoffs worth reconsidering
Edge cases you hadn't thought through
This is expected. Adding clarifications or additional requirements after seeing system design is normal. It's the system helping you think through decisions before implementation begins.
Why this matters:
Once implementation begins, requirements are locked in as build inputs. Changes after implementation starts trigger rework across affected components. The earlier you add clarifications and address gaps, the less expensive iteration becomes.
Production-ready from requirements
Morph's outcome-based pricing means you only pay for working software. "Working" is defined by your requirements.
This means requirements need to specify:
Validation criteria. What makes a workflow complete vs. incomplete?
Error conditions. What happens when things fail?
Access control. Who can do what?
Data integrity. What constraints must be enforced?
Integration behavior. How should external system failures be handled?
The more precise your requirements, the less ambiguity about what "working" means when validating the final application.
When you're uncertain
You don't need to be technical. Requirements should focus on business logic and user intent, not implementation details.
You don't need to be exhaustive. It's better to deeply specify 3 critical workflows than vaguely describe 10.
You don't need to be perfect upfront. System design will reveal gaps and ambiguities. That's the point of the phased approach.
What you do need: Clarity about what success looks like for the users and workflows you're prioritizing.
Related documentation
Requirements & System Overview - See how structured requirements translate into an actionable system architecture and implementation plan
System Design — How Morph translates requirements into technical architecture
Quick Start Guide — A fast overview to get started with your first Morph project
