Requirements Engineering Introduction

Requirements engineering is the systematic process of discovering, documenting, validating, and managing the requirements for a software system. It answers the most fundamental question in software development: "What should we build?" This question seems simple but is profoundly difficult—stakeholders often do not know exactly what they want, different stakeholders want contradictory things, and the understanding of needs evolves as the project progresses. Requirements engineering provides frameworks and techniques for navigating this complexity.

Why Requirements Engineering Matters

The most expensive software failures are not coding bugs—they are systems that work correctly but solve the wrong problem. Building the wrong thing wastes all investment in design, coding, and testing. Studies consistently show that requirements defects are the most common cause of project failure and the most expensive defects to fix when discovered late:

• Requirements defect found during analysis: $100 to fix
• Same defect found during design: $500
• Found during coding: $1,000
• Found during testing: $5,000
• Found in production: $10,000-$100,000+

The earlier requirements problems are discovered, the cheaper they are to resolve. Requirements engineering front-loads this discovery.

The Requirements Engineering Process

Elicitation gathers requirements from stakeholders and other sources. This is detective work—uncovering needs that stakeholders may not consciously recognize or cannot articulate.

Analysis examines gathered requirements for completeness, consistency, feasibility, and priority. Conflicts between stakeholders are identified and resolved. Requirements are classified and organized.

Specification documents requirements in a clear, structured format that serves as a reference for development. This might be a formal SRS document, user stories with acceptance criteria, or a product backlog.

Validation confirms that documented requirements accurately reflect stakeholder needs. Techniques include formal reviews, prototyping, and model validation.

Management handles requirements changes throughout the project lifecycle—tracking changes, assessing impacts, maintaining traceability, and ensuring consistency.

Types of Requirements

Business Requirements define high-level organizational objectives: "Reduce customer support call volume by 30% through self-service capabilities."

User Requirements describe what users need to accomplish: "Customers need to track their order status without calling support."

Functional Requirements specify system behavior: "The system shall display order status including current location, estimated delivery date, and delivery history."

Non-Functional Requirements specify system qualities: "Order status page shall load within 2 seconds for 99% of requests."

Constraints limit design choices: "Must integrate with existing SAP ERP system via standard APIs."

Real-World Example: Food Delivery App Requirements

A startup wants to build a food delivery application. Requirements engineering discovers:

From customers: Want to browse nearby restaurants, see menus with prices and photos, order with minimal clicks, track delivery in real-time, and pay securely without entering card details repeatedly.

From restaurants: Want to receive orders instantly, manage menu items and availability, see delivery time estimates, and receive payments daily.

From delivery drivers: Want clear pickup and delivery instructions, optimized routes, fair pay with tips, and flexible scheduling.

From business stakeholders: Want commission per order, delivery fee revenue, user growth metrics, and low customer acquisition cost.

Conflicts discovered during analysis:

• Customers want free delivery; business needs delivery revenue
• Restaurants want long preparation windows; customers want fast delivery
• Drivers want high per-delivery pay; business wants low delivery costs

Resolution: Tiered delivery pricing (free over $25, charged below), realistic delivery time estimates (managing expectations), and dynamic driver compensation based on distance and demand.

Requirements Engineering Challenges

Stakeholder Disagreement: Different stakeholders have different priorities. Resolution requires negotiation, prioritization, and sometimes executive decision-making.

Tacit Knowledge: Stakeholders know things they cannot articulate—workflow patterns, exceptions, implicit rules. Observation and prototyping are often more effective than interviews for uncovering tacit knowledge.

Changing Requirements: Business environments change, competitors introduce new features, regulations evolve, and users discover new needs. Requirements engineering must accommodate change without losing control.

Communication Gaps: Technical and non-technical stakeholders speak different languages. Requirements engineers bridge this gap, translating business needs into technical specifications and technical constraints into business terms.

Requirements Engineering in Agile

Agile does not eliminate requirements engineering—it distributes it throughout the project lifecycle. Instead of a single requirements phase producing a comprehensive document, Agile teams do ongoing requirements work: product backlog refinement (continuous elicitation and analysis), sprint planning (detailed specification for the upcoming iteration), sprint review (validation with stakeholders), and retrospectives (process improvement for requirements work).

Skills for Requirements Engineers

Effective requirements engineering requires: active listening (hearing what stakeholders mean, not just what they say), analytical thinking (identifying gaps, conflicts, and ambiguities), communication (writing clearly, facilitating discussions, presenting options), negotiation (resolving stakeholder conflicts), domain knowledge (understanding the business context), and technical literacy (understanding what is feasible and what is costly).