Fundamentals of Requirements Engineering

Introduction to Requirements Engineering

Requirements engineering (RE) is the disciplined process of discovering, documenting, and managing the needs and constraints of a software system. It bridges the gap between business stakeholders and technical teams, ensuring that the final product delivers real value while staying within technical, cost, and schedule limits.

In this course we will explore the fundamental concepts tested in a typical RE quiz, including feasibility studies, requirement classification, elicitation techniques, the distinction between user and system requirements, quality attributes, validation activities, traceability, and regulatory considerations.

Feasibility Studies: The First Reality Check

A feasibility study answers the essential question: Can we build the system with the resources we have? It evaluates three core dimensions:

• Technical feasibility – Are the required technologies mature and available?
• Economic feasibility – Does the projected cost fit within the budget?
• Schedule feasibility – Can the project be delivered within the required timeline?

Remember the mnemonic VCT (Viability, Cost, Time) to quickly recall these pillars.

Why Feasibility Matters

Skipping a feasibility study often leads to costly re‑work, missed deadlines, or outright project failure. By confirming feasibility early, teams avoid investing in detailed specifications for an unattainable solution.

Classifying Requirements: Functional vs. Non‑Functional

Requirements fall into two broad families:

• Functional requirements describe what the system must do – e.g., "The system shall allow users to submit a purchase order."
• Non‑functional requirements (NFRs) describe how the system performs – e.g., performance, security, reliability.

When a stakeholder claims a performance requirement is optional, the decisive factor is its classification and contractual obligation. If the requirement appears in a contract or regulatory document, it becomes mandatory regardless of stakeholder opinion. Use the mnemonic “C‑O‑N‑T‑R‑A‑T‑O” (Classification → Obligation → Not optional) to remember this rule.

Example: Performance Requirement

"The system shall generate a report within 5 seconds." This statement directly addresses the performance quality attribute, a classic non‑functional requirement.

Elicitation Best Practices: From Problem to Solution

Effective elicitation focuses on uncovering the underlying problem, not the stakeholder’s suggested solution. When a stakeholder provides a highly technical description, the analyst should:

• Ask the stakeholder to restate the need in terms of the problem it solves.
• Document the need as a high‑level requirement, postponing implementation details for later analysis.

Use the mnemonic P‑S (Problem before Solution) to keep the conversation on track.

Common Pitfalls

• Accepting implementation details as functional requirements – this can lock the project into a specific technology prematurely.
• Translating technical jargon directly into UML diagrams without clarification – leads to mis‑aligned designs.

User Requirements vs. System Requirements

Understanding the distinction between user and system requirements is crucial for clear documentation and effective communication.

• User requirements are expressed in natural language, focusing on what the user needs to achieve. They are typically high‑level, stakeholder‑friendly statements.
• System requirements translate user needs into detailed technical specifications that developers can implement.

For example, a user requirement might read, "I want to view my account balance instantly," while the corresponding system requirement could specify the API call, data format, and security checks required to fulfill that need.

Validation: Detecting Ambiguity and Ensuring Clarity

During the validation phase, the primary goal is to confirm that each requirement accurately reflects stakeholder intent. Ambiguous requirements are a common source of defects. The most effective technique to uncover ambiguity is:

• Reviewing the specification with stakeholders to identify multiple possible interpretations.

Facilitated reviews, walkthroughs, and inspections encourage stakeholders to voice doubts and clarify wording, reducing the risk of divergent implementations.

Traceability and Complexity

Traceability links each requirement to related artifacts such as design elements, test cases, and source code. When a requirement is traced to multiple test cases, it signals that the requirement is complex and requires several verification scenarios.

Benefits of Robust Traceability

• Facilitates impact analysis when changes occur.
• Ensures coverage – every requirement is verified by at least one test case.
• Supports regulatory audits by demonstrating compliance.

Regulatory Attributes and Non‑Functional Constraints

Legislation and standards often impose non‑functional constraints that must be captured as requirements. For instance, a change in data‑privacy law affects the regulatory compliance attribute of requirements.

When asked to list requirements impacted by new privacy legislation, the team should examine the non‑functional requirements that contain compliance constraints, not the functional UI specifications or performance benchmarks.

Putting It All Together: A Mini‑Workflow

1. Conduct a feasibility study – assess technical, economic, and schedule viability (VCT).
2. Elicit requirements – focus on problems, not solutions (P‑S).
3. Classify requirements – separate functional from non‑functional; verify contractual obligations (C‑O‑N‑T‑R‑A‑T‑O).
4. Document user requirements in natural language; derive system requirements with technical detail.
5. Validate – run stakeholder reviews to eliminate ambiguity.
6. Establish traceability – link each requirement to design elements and test cases; note complexity when multiple tests are needed.
7. Monitor regulatory attributes – ensure compliance requirements are up‑to‑date with legislation.

Following this structured approach helps teams deliver high‑quality software that meets business goals, stays within constraints, and complies with external regulations.

Key Takeaways

• Feasibility studies are the reality check before any detailed design.
• Non‑functional requirements tied to contracts are mandatory, not optional.
• Always steer elicitation toward the problem, not the solution.
• User requirements use natural language; system requirements are technical specifications.
• Ambiguity is best uncovered through stakeholder reviews.
• Multiple test cases linked to a requirement indicate complexity.
• Regulatory compliance is a non‑functional attribute that must be tracked.

By mastering these concepts, you will be equipped to lead successful requirements engineering efforts and produce software that truly satisfies its intended purpose.