Requirements Engineering

Introduction

Requirements engineering is the disciplined process of discovering, analyzing, documenting, validating, prioritizing, managing, and tracing what a software system must do and the conditions under which it must operate. It connects stakeholder needs with software design, implementation, testing, deployment, and maintenance. Although requirements work is often associated with the beginning of a project, requirements evolve throughout the software development life cycle (SDLC). A change in law, business strategy, technology, or user expectation can create a new requirement or alter an existing one.

A software product may fail even when its code is technically well written. Common causes include solving the wrong problem, overlooking important users, misunderstanding business rules, omitting non-functional constraints, or allowing uncontrolled changes. Requirements engineering reduces these risks by creating a shared, testable understanding of the intended product.

In practice, requirements engineering is not simply the activity of writing a list. It is a social, analytical, and technical discipline. Analysts must communicate with people who have different goals and levels of technical knowledge, resolve conflicts, identify assumptions, and translate business needs into statements that developers and testers can use.

Learning Objectives

After studying this chapter, you should be able to:

• explain the purpose and scope of requirements engineering;
• distinguish functional, non-functional, business, user, system, and transition requirements;
• elicit requirements through interviews, workshops, observation, questionnaires, document analysis, and prototyping;
• analyze requirements for ambiguity, feasibility, completeness, consistency, and testability;
• prioritize requirements using techniques such as MoSCoW and value-versus-effort analysis;
• model requirements with use cases, user stories, acceptance criteria, and simple process models;
• validate requirements with stakeholders and baseline approved versions;
• maintain traceability from needs to implementation and tests;
• recognize ethical, security, privacy, accessibility, and governance concerns in requirements work.

1. Requirements and Stakeholders

A requirement is a documented need, capability, condition, or constraint that a product, service, or process must satisfy. The term can refer to a high-level business objective or to a precise system behavior. For example, “reduce patient waiting time” is a business requirement, while “the system shall display the next available appointment within two seconds” is a system requirement.

Stakeholders are individuals, groups, or organizations that affect, are affected by, or have an interest in the system. They may include:

• customers and sponsors;
• end users and administrators;
• managers and business owners;
• developers, testers, architects, and operations staff;
• regulators, auditors, and legal advisers;
• suppliers and integration partners;
• people indirectly affected by automated decisions.

Stakeholders do not necessarily agree. A customer may want extensive reporting, a user may want simplicity, a security officer may require strong authentication, and a project manager may impose a limited budget. Requirements engineering makes these interests visible and provides a structured basis for negotiation.

Levels of Requirements

Requirements can be expressed at several levels.

Moving from business to system requirements involves increasing precision. Analysts must preserve the original purpose while avoiding premature design decisions. A requirement should state the required outcome unless a particular implementation is genuinely mandated.

2. Functional and Non-Functional Requirements

Functional requirements describe services, behaviors, calculations, responses, or transformations that the system must provide. Examples include registering a user, calculating an invoice, issuing a notification, and exporting a report.

Non-functional requirements describe qualities, constraints, or conditions governing the system or its development. Important categories include:

• Performance: response time, throughput, capacity, and resource usage;
• Security: authentication, authorization, confidentiality, integrity, and auditability;
• Usability and accessibility: learnability, clarity, keyboard access, and compatibility with assistive technologies;
• Reliability and availability: failure behavior, recovery, and permitted downtime;
• Maintainability: modularity, diagnosability, and ease of modification;
• Compatibility and portability: supported platforms, browsers, devices, and interfaces;
• Legal and regulatory compliance: privacy, records retention, safety, and sector-specific rules.

Non-functional requirements are not optional decorations. A system that performs the correct function but exposes private data or is inaccessible to its intended users is not a successful system. Non-functional requirements should be measurable wherever possible.

Compare these statements:

• Weak: “The system should be fast.”
• Stronger: “For up to 500 concurrent users, 95% of catalogue searches shall return results within two seconds, measured at the application interface.”

The stronger statement identifies a condition, a measurable threshold, and a means of verification. The target must still be agreed with stakeholders and confirmed as technically feasible.

3. The Requirements Engineering Process

A typical process contains the following related activities:

1. Inception and scope definition: understand the problem, objectives, boundaries, assumptions, and constraints.
2. Elicitation: discover needs, expectations, rules, pain points, and hidden requirements.
3. Analysis and negotiation: organize, clarify, model, check feasibility, identify conflicts, and agree priorities.
4. Specification: record requirements in an appropriate form, such as a product backlog, use-case specification, or software requirements specification.
5. Validation: check whether the documented requirements are correct, complete enough, feasible, consistent, unambiguous, and testable.
6. Baseline and change management: obtain approval for a version and control subsequent changes.
7. Traceability and monitoring: link requirements to their sources, design elements, code, tests, releases, and evidence of acceptance.

These activities overlap. For example, an interview may reveal a requirement, a prototype may expose ambiguity, and a validation workshop may generate a change. Iterative development repeats the cycle at different levels of detail.

4. Eliciting Requirements

Elicitation is the purposeful discovery of requirements. Analysts should not rely on a single technique because each technique reveals different information.

Interviews

Interviews may be structured, semi-structured, or exploratory. Effective interviews begin with objectives and identify the participant’s role. Open questions such as “How do you currently process a return?” reveal workflow, while probing questions such as “What happens when the item is damaged?” reveal exceptions. Closed questions can confirm details.

The analyst should distinguish facts from opinions, record terminology, summarize understanding, and confirm unresolved issues. Leading questions should be avoided because they encourage stakeholders to approve the analyst’s preferred solution.

Workshops

A workshop brings relevant stakeholders together to explore a process, agree terminology, prioritize needs, or resolve conflicts. A facilitator should establish an agenda, decision rules, time limits, and a method for recording actions. Techniques such as process mapping, affinity grouping, and dot voting can make discussion visible and structured. Workshops are powerful but can be dominated by senior or highly vocal participants; facilitation must protect less powerful perspectives.

Observation and contextual inquiry

Observation reveals workarounds, informal practices, interruptions, and environmental constraints that participants may not mention. An analyst might observe how warehouse staff scan items rather than asking only what the official procedure says. Observation must respect privacy, safety, consent, and the distinction between unusual behavior and a required business process.

Questionnaires and document analysis

Questionnaires efficiently gather input from many people, but they are less effective for complex or ambiguous topics. Existing forms, policies, contracts, reports, manuals, regulations, and database structures can reveal business rules and constraints. Documents should not be treated as automatically correct; they may be outdated or inconsistent with actual practice.

Prototyping

A prototype is a partial representation of a proposed product. It may be a paper sketch, clickable interface, simulation, or technical proof of concept. Prototypes help stakeholders respond to something concrete and expose usability problems and missing rules. However, users may mistake a visual mock-up for a completed system, and developers may infer technical commitments that were never approved. The prototype’s purpose and limitations should be stated explicitly.

5. Analysis, Quality, and Feasibility

After elicitation, requirements must be analyzed. Useful analysis activities include grouping related requirements, identifying duplicates, defining terms, discovering dependencies, modeling workflows, checking exceptions, and separating needs from proposed solutions.

A high-quality requirement is commonly assessed using the following characteristics:

• Correct: represents a genuine stakeholder or business need;
• Unambiguous: has one reasonable interpretation;
• Complete: includes necessary behavior, conditions, and exceptions;
• Consistent: does not conflict with another approved requirement;
• Feasible: can be delivered within technical, legal, schedule, and budget constraints;
• Verifiable: can be checked by inspection, test, demonstration, or analysis;
• Traceable: has a known source and can be linked to downstream work;
• Prioritized: has an agreed level of importance.

A useful review question is: “How would a tester prove that this requirement has been met?” If no credible answer exists, the requirement may be vague or incomplete.

Feasibility analysis

Feasibility is multidimensional. A proposal may be technically possible but legally unacceptable, or financially attractive but operationally impractical. Analysts should consider:

• technical feasibility and integration complexity;
• financial feasibility and total cost of ownership;
• operational feasibility and organizational readiness;
• legal, privacy, security, and accessibility obligations;
• schedule and resource constraints.

Assumptions and dependencies should be recorded. For example, a mobile application may depend on a reliable identity provider, a stable network connection, and access to a government service. Hidden dependencies are common sources of project risk.

6. Use Cases, User Stories, and Acceptance Criteria

Use cases

A use case describes how an actor interacts with a system to achieve a goal. A well-formed use case normally includes:

• name and goal;
• primary actor and supporting actors;
• trigger;
• preconditions;
• main success scenario;
• alternative and exception flows;
• postconditions;
• special requirements or business rules.

Illustrative use case: Submit an expense claim

• Primary actor: Employee
• Precondition: The employee is authenticated and has an active profile.
• Trigger: The employee selects “New claim.”
• Main flow: The employee enters claim details, attaches a receipt, submits the claim, and receives a reference number. The system validates required fields and routes the claim to the appropriate manager.
• Alternative flow: If the receipt format is unsupported, the system explains the problem and requests another file.
• Postcondition: The claim is stored with status “Submitted” and an audit record is created.

Use cases are especially useful for system behavior, collaboration, and exception analysis. They should describe user intent rather than screen-by-screen design.

User stories

User stories are concise statements commonly used in Agile development:

As a [role], I want [capability], so that [benefit].

Example: “As a customer, I want to save a delivery address so that I can complete future orders more quickly.”

A story is a starting point for conversation, not a complete specification. Details are developed through discussion and acceptance criteria. The INVEST heuristic is often used to assess stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable. These qualities are guidelines rather than absolute rules.

Acceptance criteria

Acceptance criteria state the conditions that must be satisfied for a requirement to be accepted. They should cover the normal outcome and important alternatives. For the delivery-address story, criteria might include:

• an authenticated customer can add an address with all mandatory fields;
• the system identifies missing or invalid fields before saving;
• the customer can select a saved address during checkout;
• the customer can edit or delete an address, subject to order-history rules;
• sensitive address data is visible only to authorized users.

Acceptance criteria support shared understanding, development, and testing. They are not merely test cases, although they can be converted into test scenarios.

7. Prioritization and Negotiation

Resources are limited, so requirements must be prioritized. MoSCoW is a practical technique:

• Must have: essential for the release or legal/business viability;
• Should have: important but a temporary workaround exists;
• Could have: desirable if time and resources permit;
• Won’t have this time: explicitly excluded from the current scope.

The “Won’t” category is valuable because it makes boundaries visible. A requirement should not be labelled “Must” merely because a stakeholder prefers it. The number of Must requirements should be realistic.

Other techniques include ranking, pairwise comparison, stakeholder voting, value-versus-effort analysis, risk reduction, and minimum viable product analysis. Prioritization should consider customer value, regulatory necessity, dependencies, architectural risk, cost, urgency, and uncertainty. Priorities may change as evidence becomes available.

Negotiation should focus on interests and outcomes rather than personalities. When requirements conflict, the analyst can document each position, identify the underlying goal, develop alternatives, evaluate consequences, and obtain a decision from the authorized product owner or governance body.

8. Modeling Requirements

Models provide simplified views of a problem. They help stakeholders see relationships that may be difficult to express in prose.

Useful models include:

• context diagrams showing system boundaries and external actors;
• use-case diagrams showing actors and goals;
• activity or process models showing flow and decisions;
• state models showing how an entity changes over time;
• data models showing entities, attributes, and relationships;
• prototypes showing interaction and layout;
• decision tables showing combinations of conditions and outcomes.

A decision table is particularly useful for complex business rules. For example, an insurance discount might depend on customer age, claim history, and membership status. The table should enumerate relevant combinations and identify the outcome for each. Models must be kept consistent with written requirements; a diagram that contradicts the specification creates rather than removes ambiguity.

9. Requirements Documentation

Documentation should be sufficiently precise for its audience without becoming unnecessary bureaucracy. A software requirements specification may contain:

1. purpose, scope, and definitions;
2. product context and stakeholders;
3. assumptions, dependencies, and constraints;
4. functional requirements;
5. non-functional requirements;
6. data and interface requirements;
7. business rules and exception behavior;
8. acceptance criteria;
9. traceability and open issues.

Each requirement should have a unique identifier, such as FR-014 or NFR-SEC-003. A useful requirement record may include description, source, rationale, priority, owner, status, dependencies, verification method, and revision history.

Good wording uses “shall” for a mandatory requirement and avoids vague terms such as “user-friendly,” “quick,” “appropriate,” and “where possible” unless they are defined. Requirements should not combine several independent obligations in one sentence because partial implementation then becomes difficult to assess.

10. Validation, Baselines, and Change Management

Validation asks whether the documented requirements describe the right product and whether they are suitable for development and testing. Reviews may be conducted through walkthroughs, inspections, prototypes, test-case derivation, and scenario-based discussions.

A validation checklist should consider:

• Does each requirement have a legitimate source?
• Is the business objective clear?
• Are actors, triggers, inputs, outputs, and exceptions identified?
• Are non-functional targets measurable?
• Are security, privacy, accessibility, and legal obligations addressed?
• Can each requirement be verified?
• Do requirements conflict with one another?
• Are assumptions and dependencies recorded?

A baseline is an agreed version of requirements that is subject to formal change control. Baselines do not mean requirements can never change. They establish a stable reference against which changes, impacts, and approvals can be managed.

A change request should identify the proposed change, reason, source, urgency, affected requirements, impact on architecture, design, code, tests, cost, schedule, risk, and compliance. An authorized person or change control group then approves, rejects, defers, or requests more analysis. Traceability makes impact analysis faster and more reliable.

11. Requirements Traceability

Traceability is the ability to follow a requirement through its origin and downstream realization. A simple traceability chain is:

Business objective → stakeholder need → system requirement → design element → implementation task → test case → acceptance evidence

A requirements traceability matrix can expose orphan requirements, untested functionality, and tests that do not correspond to an approved need. Traceability is especially important in regulated, safety-critical, financial, and security-sensitive systems. It may be lightweight in a small project, but the principle remains useful.

Traceability should be maintained in both directions. Forward traceability asks how a requirement is implemented and tested. Backward traceability asks why a design feature or test exists. A feature with no approved source may be unnecessary scope; a requirement with no implementation or test may be at risk.

12. Applied Case: Community Clinic Appointment System

The following is an illustrative case.

Background

A community clinic uses telephone calls and spreadsheets to manage appointments. Patients experience long waiting times, reception staff frequently enter duplicate records, and clinicians cannot easily see cancellations. The clinic proposes an online appointment system.

Problem analysis

Initial discussions reveal different perspectives. Patients want convenient booking and reminders. Reception staff need control over appointment types and exceptions. Clinicians need accurate schedules. The clinic manager wants fewer missed appointments. Privacy staff require protection of health-related information.

Observation shows that some appointments require preparation instructions and that urgent cases cannot be handled through ordinary online booking. This illustrates why observation and exception analysis are necessary.

Requirements approach

The analyst identifies stakeholders, maps the current process, and conducts interviews and a workshop. High-level requirements include:

• patients can view available appointment slots;
• authorized staff can create, reschedule, and cancel appointments;
• the system sends configurable reminders;
• urgent requests are directed to a telephone process rather than automatically booked;
• access to patient information is restricted by role;
• appointment changes are recorded in an audit trail.

An example acceptance criterion is: “Given an authenticated patient has selected an available routine appointment, when the patient confirms the booking, then the system shall reserve the slot, display a confirmation reference, and send a confirmation message.” Additional criteria address unavailable slots, duplicate submissions, failed notifications, and cancellation rules.

Prioritization

Must-have requirements include role-based access, appointment creation, conflict prevention, and audit logging. Should-have requirements include automated reminders and calendar integration. A patient-rating feature is deferred because it does not support the initial clinical objective.

Outcome

A clickable prototype exposes confusing terminology and shows that patients need to distinguish routine appointments from urgent concerns. A validation workshop resolves the issue before implementation. Traceability links the privacy requirement to access-control design and security tests. The case demonstrates that requirements engineering improves both product quality and organizational decision-making; it is not limited to producing documents.

13. Ethical, Legal, and Governance Considerations

Requirements decisions can distribute benefits and risks. Analysts should ask who may be excluded, monitored, misclassified, or harmed by the proposed system. Important considerations include:

• privacy by design and data minimization;
• informed consent and appropriate use of personal data;
• accessibility for users with disabilities;
• security controls proportionate to risk;
• explainability and human oversight for automated decisions;
• records retention and lawful disposal;
• fairness and non-discrimination;
• clear accountability when systems fail.

AI-assisted requirements tools may summarize interviews, identify duplicate statements, generate draft user stories, or suggest test cases. These uses can improve productivity, but generated content must be reviewed by qualified people. Confidential interview data should not be uploaded to an unauthorized service. AI output may reproduce bias, invent details, or conceal uncertainty. Human ownership, source verification, access control, and an audit trail remain essential.

14. Common Challenges and Best Practices

Common challenges include scope creep, stakeholder absence, conflicting terminology, overreliance on a single stakeholder, premature commitment to a solution, weak non-functional requirements, and failure to analyze exceptions. Agile projects may also confuse a short user story with a complete requirement, while plan-driven projects may produce large documents that nobody validates.

Professional best practices include:

• begin with the problem and measurable outcomes;
• identify stakeholders systematically, including indirect and vulnerable groups;
• combine elicitation techniques;
• maintain a glossary and define domain terms;
• record assumptions, decisions, risks, and open questions;
• express important qualities with measurable targets;
• use examples, scenarios, models, and prototypes;
• prioritize transparently and revisit priorities;
• validate continuously with appropriate stakeholders;
• baseline requirements and control changes;
• maintain practical bidirectional traceability;
• involve testers, security specialists, operations staff, and accessibility experts early.

Chapter Summary

Requirements engineering establishes a shared, testable understanding of what a software system must achieve and the constraints under which it must operate. It includes elicitation, analysis, negotiation, specification, validation, prioritization, baselining, change management, and traceability. Functional requirements describe behavior, while non-functional requirements define qualities and constraints. Interviews, workshops, observation, document analysis, questionnaires, and prototypes provide complementary evidence.

Use cases describe actor goals and interaction flows; user stories provide concise value-oriented statements; acceptance criteria define conditions for successful delivery. Models clarify processes, states, data, and decisions. High-quality requirements are correct, clear, complete enough, consistent, feasible, verifiable, prioritized, and traceable. Ethical, privacy, security, accessibility, legal, and governance concerns must be addressed from the beginning. Effective requirements engineering is continuous and collaborative, providing the foundation for design, development, testing, and successful organizational change.

Key Terms

Requirement: A need, capability, condition, or constraint that a system must satisfy.

Requirements engineering: The process of eliciting, analyzing, documenting, validating, managing, and tracing requirements.

Stakeholder: A person or organization that affects, is affected by, or has an interest in a system.

Functional requirement: A required service, behavior, calculation, or response.

Non-functional requirement: A quality attribute, constraint, or operating condition.

Business requirement: A high-level organizational objective or outcome.

User requirement: A capability expressed from a user’s perspective.

System requirement: A precise requirement for the software or system.

Elicitation: The discovery of requirements from stakeholders, documents, observation, and other evidence.

Use case: A description of interactions between an actor and a system to achieve a goal.

User story: A concise statement of a user role, desired capability, and benefit.

Acceptance criterion: A condition that must be satisfied for a requirement to be accepted.

Prototype: A partial representation used to explore, communicate, or validate a solution.

MoSCoW: A prioritization method using Must, Should, Could, and Won’t categories.

Baseline: An approved version controlled through formal change management.

Traceability: The ability to follow a requirement to its source and related deliverables.

Business rule: A policy, rule, or constraint governing organizational behavior or decisions.

Feasibility: The degree to which a proposed requirement can be delivered within relevant constraints.

Review Questions

Short Answer Questions

1. What is the difference between a functional requirement and a non-functional requirement?
2. Why should analysts identify alternative and exception flows in a use case?
3. State four characteristics of a high-quality requirement.
4. What is the purpose of a requirements baseline?
5. Name three techniques used to elicit requirements.

Long Answer Questions

1. Explain the requirements engineering process from inception through traceability, showing how the activities support one another.
2. Compare interviews, workshops, observation, document analysis, and prototyping. Identify the strengths and limitations of each.
3. Explain how user stories and acceptance criteria support Agile development, and discuss why a user story alone may be insufficient.
4. Discuss functional and non-functional requirements using a realistic information system as an example.
5. Explain how validation, change control, and traceability reduce project risk.

Analytical / Application Questions

1. A college is replacing its manual student registration process. Identify at least six stakeholders, propose five functional requirements and four non-functional requirements, and justify two priorities.
2. A requirement states: “The system shall provide fast and user-friendly reports.” Analyze its weaknesses and rewrite it as two measurable requirements, stating any assumptions.
3. A stakeholder requests facial recognition for examination attendance. Analyze the request from technical, privacy, accessibility, security, ethical, and operational perspectives, and recommend an appropriate requirements-engineering approach.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a non-functional requirement?

A. The system shall calculate the invoice total.

B. The user shall add an item to a shopping basket.

C. The system shall return 95% of searches within two seconds.

D. The administrator shall create a new account.

Correct Answer: C. The system shall return 95% of searches within two seconds.

Question 2

What is the primary purpose of acceptance criteria?

A. To select the programming language

B. To define conditions that demonstrate requirement completion

C. To replace all stakeholder interviews

D. To describe the organization’s marketing strategy

Correct Answer: B. To define conditions that demonstrate requirement completion

Question 3

Which activity is most likely to reveal informal workarounds in an existing process?

A. Observation

B. Source-code compilation

C. Database indexing

D. Unit testing

Correct Answer: A. Observation

Question 4

In MoSCoW prioritization, a “Must have” requirement is one that:

A. Would be useful only after the project ends

B. Is essential for the agreed release or viability

C. Has the lowest stakeholder value

D. Must always be implemented last

Correct Answer: B. Is essential for the agreed release or viability

Question 5

What does forward traceability connect?

A. A requirement to its implementation and tests

B. A user to a payroll record only

C. A defect to an unrelated project

D. A prototype to a programming language specification

Correct Answer: A. A requirement to its implementation and tests

Question 6

Which quality means that a requirement can be checked through testing, inspection, demonstration, or analysis?

A. Traceability

B. Verifiability

C. Portability

D. Negotiability

Correct Answer: B. Verifiability

Question 7

Why is a baseline useful?

A. It prevents every future change permanently

B. It provides an approved version against which changes can be controlled

C. It removes the need for stakeholder approval

D. It guarantees that implementation will have no defects

Correct Answer: B. It provides an approved version against which changes can be controlled

Question 8

Which is the best example of a transition requirement?

A. The system shall encrypt stored passwords.

B. The customer shall search for products.

C. Existing customer data shall be cleansed and migrated before launch.

D. The dashboard shall display monthly sales.

Correct Answer: C. Existing customer data shall be cleansed and migrated before launch.

Question 9

A user story is best understood as:

A. A complete technical architecture document

B. A concise statement of user role, capability, and benefit

C. A database table definition

D. A legal contract with a supplier

Correct Answer: B. A concise statement of user role, capability, and benefit

Question 10

Which practice is most appropriate when an AI tool generates requirements from confidential interviews?

A. Accept all generated statements without review

B. Upload the interviews to any public service

C. Verify the output, protect confidential data, and retain human ownership

D. Remove all acceptance criteria to save time

Correct Answer: C. Verify the output, protect confidential data, and retain human ownership