Imagine a team deciding to build a new learning platform, similar to CS Engineering Gyan, meant to help students track video progress, take quizzes, and download notes. Before writing a single line of code, the team needs to answer a much more fundamental question: what exactly should this platform actually do, and for whom?
Answering this question properly is far more difficult than it sounds. Different stakeholders, students, instructors, and platform administrators, often have different expectations, some of which may be vague, incomplete, or even contradictory. Requirement Engineering is the disciplined process software teams use to discover, refine, and document exactly what a system needs to do before development begins.
In this tutorial, you will learn what requirement engineering means, the different types of requirements a project must capture, the step-by-step process used to gather and refine them, common elicitation techniques, and the challenges that make this phase one of the most critical in the entire software development lifecycle.
Requirement Engineering is the systematic process of discovering, analyzing, documenting, and managing the requirements of a software system throughout its development. It forms the foundation upon which every later phase of the software development lifecycle, including design, coding, and testing, is built.
Getting requirements wrong at this early stage tends to be far more costly to fix later, since mistakes discovered during testing or after deployment often require significant rework across design and implementation as well. This is why requirement engineering is treated as a distinct, carefully managed phase rather than something teams rush through informally.
Requirements gathered during this phase are generally classified into two broad categories, each describing a different aspect of what the system must accomplish.
| Requirement Type | Description |
|---|---|
| Functional Requirements | Describe specific behaviors or functions the system must perform. |
| Non-Functional Requirements | Describe the quality attributes and constraints under which the system must operate. |
For a learning platform like CS Engineering Gyan, functional requirements might include statements such as:
Non-functional requirements for the same platform might include statements such as:
Notice how functional requirements describe specific actions the system performs, while non-functional requirements describe qualities like speed, security, and reliability that apply across the entire system rather than to any single feature.
Requirement Engineering is typically broken down into a series of interconnected activities, each building on the results of the previous one, though in practice teams often revisit earlier steps as new information emerges.
| Step | Purpose |
|---|---|
| Requirement Elicitation | Gathering requirements from stakeholders through various discovery techniques. |
| Requirement Analysis | Examining gathered requirements to resolve conflicts, ambiguities, and gaps. |
| Requirement Specification | Documenting requirements formally in a clear, structured format. |
| Requirement Validation | Confirming with stakeholders that documented requirements accurately reflect their needs. |
| Requirement Management | Tracking and controlling changes to requirements throughout the project's lifecycle. |
Requirement elicitation is the process of discovering what stakeholders actually need from the system. This is often more challenging than it appears, since stakeholders may struggle to clearly articulate their needs, may not be aware of technical constraints, or may have needs that conflict with those of other stakeholders.
| Technique | Description |
|---|---|
| Interviews | Direct conversations with stakeholders to understand their needs and expectations in detail. |
| Questionnaires | Structured sets of questions distributed to a larger group of stakeholders for broader input. |
| Brainstorming | Group sessions designed to generate a wide range of ideas and requirements collaboratively. |
| Observation | Watching how users currently perform related tasks to identify unstated needs. |
| Use Case Analysis | Describing how different types of users would interact with the system in specific scenarios. |
While planning the CS Engineering Gyan platform, the team might interview a group of engineering students to understand what frustrates them about existing learning platforms, such as difficulty tracking progress across multiple courses, while also observing how instructors currently organize and share video content informally, revealing needs that might not surface through interviews alone.
Once requirements have been gathered, they rarely arrive in a clean, consistent form. Requirement analysis involves reviewing the collected information to identify conflicts, remove ambiguity, and organize requirements into a coherent, prioritized set.
During elicitation, one stakeholder for CS Engineering Gyan might request that quizzes be mandatory before unlocking the next video, while another stakeholder might insist that students should be able to skip freely between lessons. Requirement analysis is the stage where this conflict is identified and resolved, perhaps by introducing a configurable setting that allows either behavior depending on the course.
Requirement specification involves documenting the analyzed requirements in a clear, structured, and unambiguous format that can be shared with the entire development team. This documentation typically takes the form of a Software Requirement Specification, or SRS, document.
Requirement ID: FR-014 Requirement: The system shall allow a student to download course notes in PDF format. Priority: High Source: Student stakeholder interviews conducted during elicitation phase.
Writing requirements in this structured format, rather than as loosely organized notes, makes it far easier for developers, testers, and project managers to reference specific requirements consistently throughout the project.
Requirement validation involves reviewing the documented requirements with stakeholders to confirm that they accurately and completely capture what was actually needed. This step catches misunderstandings before they turn into costly design or development mistakes.
Before development begins on CS Engineering Gyan, the documented requirements might be reviewed in a meeting with instructor representatives, who could point out that the specification failed to mention the need for instructors to edit previously uploaded video descriptions, a requirement that was discussed during elicitation but accidentally omitted during specification.
Requirements rarely remain completely static throughout a project. New insights, changing business needs, or feedback from early testing can all lead to requirement changes even after development has started. Requirement management is the ongoing process of tracking, controlling, and documenting these changes throughout the project's lifecycle.
Midway through development, the CS Engineering Gyan team might receive a new request to add support for offline video downloads. Requirement management ensures this change is properly documented, evaluated for its impact on the existing schedule and design, and formally approved before being incorporated into the project, rather than being implemented informally without review.
| Characteristic | Description |
|---|---|
| Clear and Unambiguous | The requirement can only be interpreted in one way by anyone reading it. |
| Complete | The requirement fully describes the expected behavior without leaving gaps. |
| Consistent | The requirement does not contradict any other documented requirement. |
| Verifiable | The requirement can be tested or measured to confirm it has been satisfied. |
| Traceable | The requirement can be linked back to its original source and forward to its implementation. |
| Mistake | Correct Practice |
|---|---|
| Rushing through elicitation to start development sooner. | Invest adequate time in elicitation, since early mistakes are far costlier to fix later. |
| Documenting requirements in vague, open-ended language. | Write requirements clearly enough that they can be objectively tested and verified. |
| Skipping formal validation with stakeholders before development begins. | Always confirm documented requirements with stakeholders to catch misunderstandings early. |
| Allowing requirement changes without any formal review process. | Establish a structured change management process to evaluate the impact of new requirements. |
Requirement Engineering lays the essential groundwork for every software project, ensuring that development efforts are guided by a clear, shared understanding of what the system actually needs to accomplish. Through the structured process of elicitation, analysis, specification, validation, and ongoing management, teams can transform vague stakeholder expectations, such as those that might shape a platform like CS Engineering Gyan, into precise, actionable requirements.
Understanding the distinction between functional and non-functional requirements, along with the characteristics of a well-written requirement, helps teams avoid costly misunderstandings that could otherwise surface much later in development. Investing proper time and discipline into this phase significantly reduces the risk of building a system that technically works but fails to meet the actual needs of its users.
With a solid understanding of requirement engineering, you are now ready to explore the Software Requirement Specification, which formalizes these gathered requirements into a complete, structured document used throughout the rest of the project.