Which of the following is not a phase or activity of requirement engineering in context of software engineering?

Question

Accepted Answer

The correct option is (4):
Component specification falls outside the boundary of the core requirements engineering (RE) process. Requirements Engineering is exclusively focused on establishing *what* the system must do by defining its services and operating constraints. Component specification, which involves the detailed design, structure, and interfaces of individual software modules or subsystems, is an activity that takes place during the subsequent **Software Design** phase of the Software Development Life Cycle (SDLC). It is concerned with *how* the system will be built to satisfy the requirements, not *what* the requirements are, making it a design-level decision rather than a foundational requirements activity.

The incorrect option is (1):
The **Feasibility Study** is an integral, and often the first, activity within the requirements engineering framework. Its purpose is to assess the technical, economic, legal, operational, and scheduling viability (TELOS) of the proposed software project before significant resources are committed. It provides the crucial "Go/No-Go" decision, confirming that the project is realistic and achievable with the organization's existing capabilities, thus serving as a necessary precursor to gathering detailed specifications.

The incorrect option is (2):
**Requirements Elicitation and Analysis** are the fundamental and central activities of the requirements engineering process. Elicitation is the discovery phase, involving interaction with stakeholders to gather their raw needs and constraints from various sources. Analysis immediately follows, where these requirements are carefully examined to check for clarity, consistency, and completeness, then refined, prioritized, and modeled into a structured set of specifications. Without these two steps, no requirements document can be produced.

The incorrect option is (3):
**Requirement Validation** is a critical quality assurance activity performed as the requirements phase nears completion. Its goal is to ensure the complete set of documented requirements accurately reflects the stakeholder's true needs and that the system, if built to these specifications, will solve the original business problem—often summarized as ensuring "we are building the right product." This step involves reviews, walkthroughs, and checks for verifiability and consistency to minimize costly errors.