Introduction
Requirements engineering is the process of discovering, documenting, and maintaining the requirements a software system must satisfy. Getting requirements right is often the single biggest factor in project success, since errors introduced at this stage are typically the most expensive to fix later in the lifecycle.
Cricket analogy: Before a series, the team management studies the pitch report, opposition weaknesses, and player fitness so the squad selected actually fits the conditions; a wrong read of the pitch, discovered mid-series, is far costlier to fix than getting it right in the selection meeting.
Explanation
Requirements are commonly split into two categories. Functional requirements describe what the system must do — specific behaviors, features, and interactions, such as 'the system shall allow a user to reset their password via email.' Non-functional requirements describe how the system must perform its functions — qualities such as performance, security, usability, availability, and scalability, such as 'the system shall respond to 95% of requests within 200 milliseconds.' Both types are essential: a system that does the right things but is too slow, insecure, or unreliable will still fail to satisfy its users.
Cricket analogy: A team needs both the functional requirement of scoring 300 runs and the non-functional requirement of doing it within 50 overs at an acceptable run rate; a team that scores runs too slowly, like a side crawling to 300 in 60 overs, still fails the format's constraints.
The requirements process typically follows four stages. Elicitation involves gathering requirements from stakeholders through interviews, surveys, workshops, observation, and reviewing existing documentation. Analysis involves examining the gathered requirements for conflicts, ambiguities, gaps, and feasibility, and negotiating priorities among stakeholders. Specification involves documenting the requirements clearly and precisely, often using structured formats such as user stories, use cases, or formal requirement statements, so they can be understood and verified consistently. Validation involves confirming with stakeholders that the specified requirements are correct, complete, and actually reflect what is needed, often through reviews, prototypes, or acceptance criteria, before significant development effort is invested.
Cricket analogy: Selectors gather input from coaches and scouts (elicitation), debate and resolve conflicting opinions about who fits the XI (analysis), announce the final squad list clearly (specification), and confirm it with the board and captain before the series starts (validation).
Example
# A simple structure for capturing requirements
requirements = [
{
"id": "FR-1",
"type": "functional",
"description": "The system shall allow a user to reset their password via email.",
},
{
"id": "NFR-1",
"type": "non-functional",
"description": "The system shall respond to 95% of requests within 200 milliseconds.",
},
]
def validate_requirement(req):
required_fields = {"id", "type", "description"}
missing = required_fields - req.keys()
if missing:
raise ValueError(f"Requirement {req.get('id')} missing fields: {missing}")
if req["type"] not in ("functional", "non-functional"):
raise ValueError(f"Requirement {req['id']} has invalid type")
return True
for req in requirements:
validate_requirement(req)
print(f"{req['id']} ({req['type']}): {req['description']}")Analysis
Treating requirements engineering as a distinct, disciplined activity — rather than an informal conversation before coding starts — reduces costly rework. The functional/non-functional split forces teams to consider quality attributes early rather than treating them as afterthoughts, since retrofitting performance or security into a finished system is far more expensive than designing for them from the start. The four-stage process (elicitation, analysis, specification, validation) ensures requirements are not just collected but also checked for conflicts, clearly documented, and confirmed with stakeholders, catching misunderstandings before they become expensive defects discovered late in testing or, worse, in production.
Cricket analogy: Running a formal team meeting with coach, selectors, and captain before finalizing a squad, rather than a casual chat in the dressing room, catches mismatches like an all-pace attack on a spin-friendly pitch before the toss, not after a first-innings collapse.
Key Takeaways
- Functional requirements define what a system must do; non-functional requirements define how well it must do it.
- The requirements process has four stages: elicitation, analysis, specification, validation.
- Errors in requirements are typically the most expensive to fix later in the lifecycle.
- Validation with stakeholders confirms requirements are correct and complete before major development investment.
Practice what you learned
1. What is the difference between functional and non-functional requirements?
2. Which of the following is an example of a non-functional requirement?
3. What is the purpose of the elicitation stage in requirements engineering?
4. Why is validation an important stage in the requirements process?
Was this page helpful?
You May Also Like
SDLC Models
A comparison of Waterfall, Iterative/Incremental, Spiral, and Agile software development lifecycle models and their tradeoffs.
Agile and Scrum
An introduction to the Agile Manifesto's core values and the Scrum framework's roles, ceremonies, and artifacts.
Software Documentation
Learn the major types of software documentation and how each serves a distinct audience and purpose.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 40 topics