What is the "risk-based" approach to Requirements Engineering under time pressure?

Risk — not the clock — defines how much effort each requirement gets: specify risky things in depth, low-risk things lightly, and accept "good enough" over perfect.

Under time pressure you can't specify everything perfectly, so focus depth where the risk is highest:

1. Risk-based specification: Risk defines the effort, not time available
2. Unequal depth/coverage: Risky things documented in more detail, less risky things less detailed
3. Incremental development: Try to go for incremental development/implementation
4. Good enough over perfect: Don't try to specify "perfectly" - good enough will do

The key insight: In reality, you cannot perfectly specify everything. Focus effort where the risk is highest.

Risk factors to consider:

• Technical complexity (new technology = higher risk)
• Business criticality (payment processing vs. "About Us" page)
• Security sensitivity (authentication vs. color themes)
• Regulatory requirements (healthcare, finance = must be detailed)
• Integration points (external APIs = document thoroughly)