Software Requirements Engineering (SRE) is the systematic process of discovering, analyzing, documenting, validating, and managing the requirements of a software system.
Before developers write code, they need to understand what the software should do, who will use it, what constraints exist, and what the expected results are. Requirements Engineering provides a structured way to answer these questions.
A well-engineered requirements specification reduces misunderstandings between customers, users, developers, testers, and project managers. Poor requirements, on the other hand, can lead to rework, project delays, increased cost, and software that does not satisfy user needs.
What is Software Requirements Engineering? #
Software Requirements Engineering is a collection of activities used to identify and manage the requirements of a software system throughout its development lifecycle.
In simple words:
Requirements Engineering means understanding what the customer needs, documenting those needs clearly, checking whether they are correct, and managing them when they change.
It is not limited to writing a requirements document. It starts with understanding stakeholder needs and continues throughout the software development process.
Why is Requirements Engineering Important? #
Requirements form the foundation of a software project. Design, coding, testing, deployment, and maintenance all depend on having a clear understanding of the requirements.
For example, suppose a university wants an online examination system. The development team cannot simply start coding. They first need to understand:
- Who can create examinations?
- Who can take examinations?
- How should students log in?
- What types of questions are supported?
- How should marks be calculated?
- When should results be displayed?
- How should cheating be handled?
- What reports should administrators receive?
These questions are addressed through Requirements Engineering.
Requirements Engineering Process #
The major activities of Requirements Engineering can be represented as follows:
These activities are closely related and may occur repeatedly during a project. Requirements are often refined as stakeholders and developers gain a better understanding of the system.
1. Requirements Elicitation #
Requirements Elicitation is the process of discovering and collecting requirements from customers, users, domain experts, managers, and other stakeholders.
The objective is to understand what different stakeholders expect from the software.
Who are Stakeholders? #
A stakeholder is any person or organization that has an interest in, interacts with, is affected by, or can influence the software system.
For an online university examination system, stakeholders may include:
- Students
- Teachers
- Examination administrators
- University management
- System administrators
- IT support staff
Common Requirements Elicitation Techniques #
Interviews #
The analyst directly asks stakeholders questions to understand their needs.
Example: A software analyst interviews teachers to understand how they currently create and evaluate examinations.
Advantages:
- Provides detailed information.
- Allows follow-up questions.
- Helps uncover hidden requirements.
Questionnaires #
Questionnaires are useful when information must be collected from a large number of users.
Example: A university sends a questionnaire to 5,000 students asking about their preferred examination features.
Observation #
The analyst observes users while they perform their normal activities.
This can reveal requirements that users may forget or fail to mention during interviews.
Example: Instead of simply asking a bank employee how loan applications are processed, an analyst observes the complete process.
Workshops #
Workshops bring multiple stakeholders together to discuss requirements and reach a common understanding.
They are particularly useful when different stakeholders have conflicting requirements.
Brainstorming #
Brainstorming encourages participants to generate a large number of ideas before evaluating them.
Document Analysis #
Existing documents, forms, reports, manuals, policies, and legacy system documentation can be analyzed to identify requirements.
Prototyping #
A prototype can be created when users have difficulty explaining what they want.
Users can interact with the prototype and provide feedback, helping the development team understand the requirements more clearly.
2. Requirements Analysis #
After collecting requirements, they need to be analyzed carefully.
Requirements Analysis involves examining, organizing, prioritizing, and resolving conflicts among collected requirements.
During analysis, analysts determine:
- Whether requirements are feasible.
- Whether requirements conflict with each other.
- Whether requirements are complete.
- Whether requirements are ambiguous.
- Which requirements have higher priority.
- Whether technical and business constraints exist.
Example of Requirement Conflict #
Suppose the university examination administrator says:
“Students must be able to change their answers at any time.”
Meanwhile, the security team says:
“Answers must become permanently locked after submission.”
These requirements need to be analyzed and clarified before development begins.
Requirements Classification #
Requirements can be classified into several categories.
Functional Requirements #
Functional requirements describe what the system should do.
Examples:
- The system shall allow students to log in.
- The system shall allow teachers to create examinations.
- The system shall calculate examination scores.
- The system shall generate student result reports.
Non-Functional Requirements #
Non-functional requirements describe how well the system should perform or constraints under which it must operate.
Examples include:
- Performance
- Security
- Reliability
- Usability
- Scalability
- Availability
- Maintainability
Example: “The system should display the examination dashboard within two seconds under normal operating conditions.”
Functional vs Non-Functional Requirements #
| Functional Requirement | Non-Functional Requirement |
|---|---|
| Describes what the system does | Describes how the system performs |
| Usually represents a system function | Usually represents a quality attribute or constraint |
| Example: User can upload a document | Example: Upload should complete within 3 seconds |
3. Requirements Prioritization #
Not every requirement has the same importance. Requirements should therefore be prioritized.
A commonly used approach is to classify requirements as:
- Must Have: Essential for the system.
- Should Have: Important but not absolutely essential.
- Could Have: Useful additional functionality.
- Won’t Have: Not planned for the current release.
Example: For an online examination system, student login and examination submission may be mandatory, while dark mode may be considered a lower-priority feature.
4. Requirements Specification #
Requirements Specification is the process of documenting the agreed requirements in a clear, structured, and understandable form.
The main document used for this purpose is commonly called the Software Requirements Specification (SRS).
What is SRS? #
Software Requirements Specification (SRS) is a formal document that describes the functional and non-functional requirements of a software system.
It acts as an agreement and communication reference between stakeholders and the development team.
Typical Contents of an SRS #
- Introduction
- Purpose of the system
- Scope
- Definitions and terminology
- Overall system description
- Functional requirements
- Non-functional requirements
- User requirements
- System requirements
- External interface requirements
- Constraints
- Assumptions and dependencies
Example SRS Requirement #
A poorly written requirement might say:
“The system should be fast.”
This requirement is ambiguous because “fast” can mean different things to different people.
A better requirement would be:
“The system shall display the student’s examination dashboard within two seconds for at least 95% of requests under the specified normal load.”
The second requirement is much more measurable and testable.
Characteristics of a Good Requirement #
A good requirement should have several important characteristics.
Correct #
The requirement should accurately represent the actual stakeholder need.
Unambiguous #
The requirement should have only one reasonable interpretation.
Complete #
Important information should not be missing.
Consistent #
The requirement should not conflict with another requirement.
Feasible #
The requirement should be technically, financially, and operationally achievable.
Verifiable #
It should be possible to test whether the requirement has been satisfied.
Traceable #
The requirement should be traceable to its source and related design, implementation, and testing activities.
5. Requirements Validation #
Requirements Validation is the process of checking whether the documented requirements accurately represent the intended system and satisfy the required quality criteria.
Validation attempts to identify problems before they become expensive to fix during design or implementation.
Requirements Validation Checks #
Validity #
Does the requirement actually represent a real stakeholder need?
Consistency #
Do any requirements contradict each other?
Completeness #
Are all important system functions and constraints included?
Realism #
Can the requirement realistically be implemented with the available technology, budget, time, and resources?
Verifiability #
Can testers determine whether the requirement has been satisfied?
Requirements Review #
A requirements review is a structured examination of requirements by stakeholders and members of the development team.
Review participants may include:
- Customers
- End users
- Business analysts
- Software developers
- Test engineers
- Project managers
- Domain experts
The purpose is to identify errors, omissions, inconsistencies, ambiguities, and unrealistic requirements before development proceeds too far.
6. Requirements Management #
Requirements rarely remain completely unchanged during a software project’s lifecycle.
Requirements Management is the process of identifying, documenting, tracking, controlling, and managing changes to requirements throughout the project.
Requirements may change because of:
- Changes in business needs
- New laws or regulations
- Customer feedback
- Market changes
- Technical limitations
- Security requirements
- New technologies
- Changes in project scope
Requirements Change Management #
A requirement should not normally be changed informally after development has started. A controlled change process helps determine the impact of a proposed change.
Impact Analysis #
Before accepting a change, the team should determine what parts of the project will be affected.
Impact analysis may consider:
- Requirements
- System architecture
- Database design
- Source code
- APIs
- User interface
- Testing
- Schedule
- Project cost
Requirements Traceability #
Requirements Traceability means maintaining relationships between requirements and other development artifacts such as design components, source code, and test cases.
For example:
Requirement → Design → Code → Test Case
If a requirement changes, traceability helps the development team identify the related parts of the system that may need modification.
Real-Life Example: Online Examination System #
Consider a university developing an online examination platform.
Step 1: Elicitation #
The development team interviews teachers, students, administrators, and examination officers.
They discover requirements such as:
- Students must authenticate before taking an examination.
- Teachers must be able to create questions.
- Students must be able to submit answers.
- The system must calculate marks.
- Administrators must be able to generate reports.
Step 2: Analysis #
The team examines the requirements and identifies conflicts and dependencies.
For example, the team determines that examination submission must be protected against accidental duplicate submissions.
Step 3: Specification #
The requirements are documented in the SRS.
For example:
“The system shall allow an authenticated student to submit an examination only once unless an authorized administrator reopens the attempt.”
Step 4: Validation #
Teachers, administrators, developers, and testers review the requirement.
They check whether it is clear, complete, feasible, consistent, and testable.
Step 5: Management #
Later, the university decides that students should receive a warning when five minutes remain.
This becomes a change request. The development team analyzes the impact on the user interface, examination timer, notification system, testing, and possibly the backend.
Requirements Engineering and the SDLC #
Requirements Engineering has a strong relationship with the Software Development Life Cycle.
Requirements provide the foundation for later activities.
If requirements are misunderstood at the beginning, the mistake can propagate into design, implementation, and testing.
Common Problems in Requirements Engineering #
Ambiguous Requirements #
A requirement may have multiple interpretations.
Example: “The application should load quickly.”
The term “quickly” should be replaced with a measurable performance requirement.
Incomplete Requirements #
Important conditions or system behavior may be missing.
Conflicting Requirements #
Different stakeholders may request incompatible features.
Changing Requirements #
Business and user needs can change during development.
Communication Problems #
Customers, developers, and users may understand the same requirement differently.
Unrealistic Requirements #
A customer may request functionality that cannot be delivered within the available budget, technology, or schedule.
Requirements Engineering vs Requirements Management #
| Requirements Engineering | Requirements Management |
|---|---|
| Focuses on discovering and defining requirements. | Focuses on controlling and maintaining requirements. |
| Includes elicitation, analysis, specification, and validation. | Includes change management, traceability, versioning, and status tracking. |
| Primarily establishes what the system should provide. | Ensures requirements remain controlled throughout the project. |
Requirements Engineering vs Software Design #
| Requirements Engineering | Software Design |
|---|---|
| Defines what the system should do. | Defines how the system will be built. |
| Focuses on user and business needs. | Focuses on architecture and technical solutions. |
| Produces artifacts such as SRS. | Produces architecture and design specifications. |
Why Poor Requirements Cause Project Failure #
Many software problems can originate from misunderstandings in requirements.
Consider a simple example. A client asks for a “secure login system.” If the development team interprets this only as username and password authentication while the client expected multi-factor authentication, the resulting system may not satisfy the actual requirement.
Discovering this difference after implementation can require changes to the user interface, backend authentication, database, APIs, testing, and deployment configuration.
This is why requirements should be clarified and validated as early as possible.
Exam-Oriented Points to Remember #
- Requirements Elicitation: Collecting and discovering requirements from stakeholders.
- Requirements Analysis: Examining, organizing, prioritizing, and resolving requirement conflicts.
- Requirements Specification: Documenting requirements, commonly through an SRS.
- Requirements Validation: Checking whether requirements are correct, complete, consistent, feasible, and verifiable.
- Requirements Management: Controlling requirements and their changes throughout the project.
- Functional Requirement: Describes what the system should do.
- Non-Functional Requirement: Describes quality attributes or constraints.
- SRS: Software Requirements Specification.
- Stakeholder: A person or organization affected by or interested in the system.
- Traceability: Ability to follow a requirement through related development artifacts.
- Impact Analysis: Determining what parts of the project will be affected by a requirement change.
Frequently Asked Questions #
What is Software Requirements Engineering? #
Software Requirements Engineering is the systematic process of eliciting, analyzing, specifying, validating, and managing software requirements.
What are the five major activities of Requirements Engineering? #
The major activities are requirements elicitation, requirements analysis, requirements specification, requirements validation, and requirements management.
What is requirements elicitation? #
Requirements elicitation is the process of discovering and collecting requirements from stakeholders using techniques such as interviews, questionnaires, observation, workshops, brainstorming, document analysis, and prototyping.
What is SRS? #
SRS stands for Software Requirements Specification. It documents the agreed requirements of a software system.
What is the difference between functional and non-functional requirements? #
Functional requirements describe what the system should do, while non-functional requirements describe qualities, constraints, or performance characteristics of the system.
Why is requirements validation necessary? #
Requirements validation helps identify errors such as ambiguity, incompleteness, inconsistency, infeasibility, and lack of testability before they cause problems during later development stages.
What is requirements management? #
Requirements management involves tracking, documenting, controlling, and managing requirements and their changes throughout the software lifecycle.
Conclusion #
Software Requirements Engineering is one of the most important activities in software development because it establishes a clear understanding of what the system must provide.
The process begins with elicitation, where requirements are collected from stakeholders. The requirements are then analyzed, specified in a structured form such as an SRS, and validated to ensure they are correct and testable. Finally, requirements management ensures that requirements remain controlled as the project evolves.
A simple way to remember the complete process is:
Elicit → Analyze → Specify → Validate → Manage
Understanding these activities is essential for software engineering students because Requirements Engineering connects the needs of users and organizations with the technical work performed by software development teams.
