Requirements Engineering

Introduction and Context

Requirements engineering is the systematic process of discovering, analyzing, documenting, validating, prioritizing, and controlling what a software system must do and the conditions under which it must operate. It is not limited to writing a list of features. It connects organizational goals, stakeholder needs, user activities, technical constraints, legal obligations, and quality expectations to an implementable software product.

For full-stack developers, requirements engineering is especially important because modern applications cross several boundaries: browser or mobile interface, application services, databases, external APIs, identity systems, infrastructure, and operational support. A vague requirement at the interface may become an incorrect database model; an omitted security requirement may become a serious vulnerability; and an ambiguous performance expectation may produce a system that works in development but fails under real demand.

A useful distinction is between a problem domain and a solution domain. The problem domain contains the business or social problem to be addressed. The solution domain contains the proposed software, architecture, interfaces, and implementation. Requirements engineering should first establish what outcome is needed before prematurely deciding how it will be implemented.

Learning Objectives

After studying this chapter, you should be able to:

• distinguish functional, non-functional, business, user, system, and transition requirements;
• identify stakeholders and elicit requirements through interviews, observation, workshops, document analysis, and prototypes;
• analyze requirements for ambiguity, feasibility, conflicts, dependencies, and completeness;
• express behavior using use cases, user stories, scenarios, and acceptance criteria;
• prioritize requirements using transparent methods such as MoSCoW and value-risk reasoning;
• specify requirements that are clear, testable, traceable, and appropriately detailed;
• validate requirements with reviews, models, prototypes, and test-oriented criteria;
• manage requirements through baselines, traceability, versioning, and change control; and
• evaluate ethical, legal, security, accessibility, and AI-related implications.

Requirements as a Contract for Shared Understanding

A requirement is a condition or capability needed by a stakeholder or required by a system to solve a problem or achieve an objective. Requirements may be expressed at different levels. A business requirement states an organizational goal, such as reducing appointment no-shows. A user requirement describes what a user needs, such as receiving a reminder before an appointment. A system requirement gives sufficient precision for design and testing, such as: “The system shall send an SMS reminder 24 hours before an appointment, provided the patient has consented to SMS communication.”

Requirements are often classified as follows:

Functional requirements answer “what does the system do?” Non-functional requirements answer “how well, how securely, or under what constraints does it do it?” The distinction is useful but not absolute. For example, “The system shall encrypt stored payment tokens” describes a security quality and a concrete system behavior. The important issue is that both behavior and quality must be made explicit and testable.

A high-quality requirement is usually correct, necessary, unambiguous, consistent, complete enough for its purpose, feasible, verifiable, traceable, and prioritized. These qualities can conflict. Excessive detail early in discovery may create false certainty, whereas insufficient detail during implementation creates interpretation disputes. Requirements should therefore be developed iteratively, with the appropriate level of precision for the decision being made.

The Requirements Engineering Process

A practical process contains interconnected activities rather than a rigid sequence:

1. Inception and scope definition: establish the problem, objectives, boundaries, assumptions, and initial stakeholders.
2. Elicitation: obtain information from people, existing systems, documents, observation, and experiments.
3. Analysis and negotiation: structure information, identify conflicts and dependencies, assess feasibility, and agree on priorities.
4. Specification: record requirements in forms suitable for communication, design, development, and testing.
5. Validation: check whether the documented requirements describe the right system and can be built and tested.
6. Management: control versions, traceability, changes, decisions, and relationships throughout the lifecycle.

Agile development does not remove these activities. It distributes them across product discovery, backlog refinement, iteration planning, design, implementation, review, and release. Traditional projects may produce a formally approved requirements specification before construction; agile teams often maintain a progressively elaborated product backlog. Both approaches require disciplined reasoning and stakeholder agreement.

Figure: Requirements engineering is an iterative cycle in which learning and agreement are continuously refined.

Eliciting Requirements

Elicitation is an investigation, not a transcription exercise. Stakeholders may describe symptoms rather than underlying needs, omit tacit work practices, disagree about priorities, or use terms differently. The analyst must ask about goals, exceptions, data, decisions, constraints, and evidence.

Interviews

Interviews may be structured, semi-structured, or exploratory. A good interview plan identifies the purpose, participants, questions, evidence to collect, and follow-up actions. Open questions such as “How do you handle a failed payment?” reveal processes and exceptions. Probing questions such as “What happens next?” and “Who approves this?” expose responsibilities and workflow rules. Closed questions are useful for confirming details, not for discovering an entire domain.

Interviewers should avoid leading questions, premature solution assumptions, and accepting general statements such as “the system must be user-friendly” without clarification. A brief playback at the end—“I understand that… Is that correct?”—reduces misunderstanding.

Observation and contextual inquiry

Observation reveals the difference between prescribed work and actual work. An employee may maintain a spreadsheet because the official application is slow, or may use an informal workaround that no interview participant considers worth mentioning. Observation must respect privacy, obtain permission, and distinguish what is observed from what is inferred. The analyst should record actors, triggers, inputs, decisions, exceptions, hand-offs, and delays without unnecessarily collecting personal data.

Workshops and collaborative discovery

Workshops bring users, domain experts, product owners, developers, testers, security specialists, and operations personnel together. Techniques include brainstorming, process mapping, event storming, story mapping, affinity grouping, and prioritization exercises. A skilled facilitator makes disagreements visible without allowing the loudest participant to determine the outcome. Decisions, unresolved questions, owners, and deadlines should be recorded.

Documents, systems, and data

Existing policies, forms, reports, contracts, support tickets, database schemas, logs, and regulatory documents are valuable sources. They should be treated as evidence, not automatically as truth. A legacy form may contain fields no longer needed, while a support log may reveal an important failure mode. Data profiling can identify missing values, duplicate records, inconsistent codes, and retention concerns.

Prototypes

A prototype is a deliberately incomplete representation used to learn. Low-fidelity sketches are efficient for exploring navigation and concepts. High-fidelity interactive prototypes can examine workflow, accessibility, and content before implementation. Prototypes reduce uncertainty but can create false expectations if stakeholders mistake them for finished software. Every prototype should state its purpose, level of fidelity, assumptions, and unresolved issues.

Analysis, Modeling, and Negotiation

Analysis transforms raw statements into a coherent model. The analyst identifies actors, goals, entities, events, business rules, dependencies, constraints, and quality attributes. Useful models include context diagrams, process models, state diagrams, domain models, data models, decision tables, and story maps. Models expose missing information because relationships and transitions must be made explicit.

Consider the statement: “Users can cancel an order.” Analysis must ask: Who may cancel? Until what point? Is a reason required? Is a refund automatic? What if shipment has begun? Does cancellation create an audit record? Can an administrator override the rule? Each question may generate a requirement, business rule, or unresolved decision.

Requirements frequently conflict. Marketing may request anonymous checkout, security may require account verification, and finance may require an auditable customer identity. Negotiation should make the conflict, impact, evidence, and alternatives explicit. Decisions can be evaluated against business value, risk, cost, legal obligations, technical feasibility, and user impact. A requirement that is legally mandatory cannot be treated as equivalent to a desirable convenience feature.

Dependencies also matter. A reporting feature may depend on data retention, event capture, and a stable definition of “completed order.” A mobile feature may depend on API capabilities and offline synchronization. Recording dependencies helps teams sequence work and identify risks early.

Use Cases, User Stories, and Acceptance Criteria

A use case describes interactions between an actor and a system to achieve a goal. A concise use-case structure includes name, goal, primary actor, trigger, preconditions, main success scenario, alternative or exception flows, postconditions, and special requirements. For example, “Submit Assignment” may include a main flow for a valid file and an alternative flow for an unsupported format or submission after the deadline.

User stories are compact agile expressions of value, commonly written as:

As a [type of user], I want [capability], so that [benefit].

For example: “As a student, I want to see the receipt for my submission so that I can confirm that it was received.” The format is a conversation prompt, not a complete specification. It should be accompanied by acceptance criteria, design discussion, and relevant constraints.

Acceptance criteria define conditions that must be satisfied for a requirement to be accepted. They may be expressed as examples:

• Given a student has an active course enrollment, when a permitted file is uploaded before the deadline, then the system stores the file and displays a timestamped receipt.
• Given the file exceeds the configured limit, when the student selects Submit, then the system rejects it, explains the limit, and does not create a submission.

Good criteria are observable, deterministic, and testable. They cover normal behavior, boundary conditions, errors, permissions, data effects, and relevant quality attributes. “The page is attractive” is not a useful criterion; “Keyboard users can complete submission without a pointer device” is more verifiable and relates to accessibility.

Writing Effective Specifications

A requirement should use consistent terms and avoid vague adjectives such as fast, easy, flexible, secure, or adequate unless they are operationalized. Prefer “The search results page shall display within two seconds for at least 95% of requests under the agreed test workload” to “Search shall be fast.” The numerical target is meaningful only when workload, measurement point, environment, and percentile are defined.

Requirements should separate mandatory behavior from design suggestions. “The system shall retain an immutable audit event for each permission change” states a need; “Use framework X” is an implementation constraint and should be justified separately. Each requirement should have a unique identifier, source, rationale, priority, owner, status, and verification method where practical.

Non-functional requirements deserve early attention. Important categories include:

A useful specification is neither an enormous document nor an unstructured backlog. It is an appropriate representation of agreed knowledge, linked to evidence and kept current.

Prioritization

Prioritization determines what must be delivered, when, and with what trade-offs. MoSCoW classification labels requirements as Must, Should, Could, or Won’t have for the current release. “Must” should mean that release success is impossible without the requirement, not merely that a stakeholder strongly prefers it. A second useful view considers value, urgency, risk reduction, dependency, cost, and confidence.

A simple weighted scoring approach can support discussion. Suppose a team rates each candidate from 1 to 5 for value, urgency, risk reduction, and confidence, and rates effort from 1 to 5. One possible decision aid is:

Here, V, U, R, and C are ratings for value, urgency, risk reduction, and confidence; E is estimated effort; and the w terms are agreed non-negative weights. This is not a universal law or an objective measure of value. It is applicable only when the rating scale and weights are defined consistently. It should support, not replace, stakeholder judgment, legal analysis, or technical risk assessment. Because the numerator is a weighted rating and the denominator is an effort rating rather than a physical unit, the score has no universal unit and should be compared only within the same evaluation exercise.

For example, with equal weights, a requirement rated V = 5, U = 4, R = 3, C = 4, and E = 2 has Score = (5 + 4 + 3 + 4) ÷ 2 = 8. A requirement rated 4, 3, 5, 3, and 4 has Score = 15 ÷ 4 = 3.75. The first ranks higher under this scheme, but a mandatory legal requirement could still outrank both regardless of score.

Validation and Verification of Requirements

Validation asks whether the team is building the right product; verification asks whether the requirements are expressed correctly and can be checked. Reviews should examine:

• Validity: Does the requirement support a real stakeholder or business need?
• Completeness: Are important functions, data, exceptions, roles, and quality attributes included?
• Consistency: Do requirements contradict one another?
• Feasibility: Can the requirement be delivered within technology, time, budget, and legal constraints?
• Unambiguity: Would competent readers interpret it in the same way?
• Verifiability: Can inspection, analysis, demonstration, or testing determine compliance?
• Traceability: Can it be linked to its source, implementation, and verification evidence?

Validation techniques include peer reviews, stakeholder walkthroughs, prototypes, simulations, model checking, test-case generation, and glossary reviews. Writing a test before implementation often reveals ambiguity. For instance, “The system shall prevent unauthorized access” requires clarification of identity proofing, authorization rules, denied behavior, logging, and session management.

Traceability connects requirements across the lifecycle. A typical chain is business objective → stakeholder requirement → system requirement → design element → code change → test case → test result. A traceability matrix may reveal a design or test item with no requirement, or a requirement with no implementation and test evidence. Traceability is particularly important in regulated or safety-sensitive environments, but it is useful in ordinary applications when changes and defects must be analyzed.

Requirements Management and Change Control

Requirements evolve because markets, laws, technologies, risks, and stakeholder understanding evolve. Change is not inherently failure; uncontrolled change is the problem. Requirements management establishes identifiers, baselines, status values, ownership, version history, links, and approval rules.

A change request should state the proposed change, reason, source, urgency, affected requirements, alternatives, estimated effort, risks, dependencies, compliance effects, and decision. An appropriate authority—such as a product owner, change control board, or delegated team—then accepts, rejects, defers, or requests analysis. After approval, linked designs, code, tests, documentation, training, and release notes must be updated.

A baseline is a formally agreed version used as a reference. In an agile setting, a sprint or release commitment can act as a practical baseline even though the product backlog remains changeable. Version control should preserve history rather than silently overwriting prior decisions. “Configuration management” extends this discipline to the complete set of controlled software and documentation artifacts.

Illustrative Case: University Equipment Booking System

Background

A university currently manages laboratory-equipment bookings through email and spreadsheets. Students request equipment, technicians approve requests, and departments need reliable records for maintenance and accountability.

Problem

Double bookings occur, approval decisions are difficult to audit, and technicians cannot easily identify overdue returns. Stakeholders initially request “an online booking system,” but this is a solution label rather than a sufficiently analyzed requirement.

Analysis

Interviews identify students, technicians, department managers, and IT operations as stakeholders. Observation shows that technicians inspect equipment condition before and after use. Document analysis reveals insurance rules and a requirement that certain equipment may be issued only after safety training. Important domain rules include: an item cannot have overlapping approved bookings; only trained users may request restricted equipment; and damaged equipment must be marked unavailable pending inspection.

A prototype exposes a usability issue: students think selecting a date means immediate approval. The interface is revised to distinguish “request submitted” from “booking approved.” Acceptance criteria are written for successful requests, conflicts, missing training, cancellation, overdue return, and equipment damage.

Approach and solution

The first release prioritizes identity integration, equipment availability, request submission, approval workflow, notifications, and an audit history. A reporting dashboard is classified as a later feature. Non-functional requirements include accessibility for keyboard and screen-reader users, authorization by role, audit retention, and defined response targets for availability searches. Trace links connect each rule to stakeholder evidence, implementation tasks, and tests.

A change request later proposes allowing external visitors to book equipment. Impact analysis identifies new identity verification, liability, training, privacy, and approval requirements. The team does not simply add a “visitor” checkbox; it evaluates the wider change and defers it until governance decisions are complete.

Outcome and learning points

The resulting system reduces ambiguity by representing equipment status and approval explicitly. The case demonstrates that requirements engineering uncovers domain rules, distinguishes goals from solutions, incorporates non-functional concerns early, and makes future changes safer through traceability.

Challenges, Ethics, and Governance

Requirements work involves power and representation. Analysts should ask whose needs are absent: users with disabilities, occasional users, people with limited connectivity, non-native speakers, support staff, and people affected by automated decisions. Accessibility and inclusion are requirements concerns, not cosmetic enhancements.

Privacy requires data minimization, purpose limitation, appropriate access, retention rules, transparency, and secure disposal. Personal data should not be collected merely because it might be useful later. Security requirements should address threats, authentication, authorization, secrets, logging, recovery, and abuse cases. Legal and regulatory obligations must be interpreted with qualified specialists; a requirements document is not a substitute for legal advice.

AI-assisted elicitation and coding can summarize interviews, cluster feedback, generate draft stories, or identify contradictions. However, generated text may invent requirements, reproduce bias, expose confidential information, or obscure the source of a decision. Human stakeholders must validate outputs, sensitive material must be handled according to policy, and every important requirement should retain provenance. AI may accelerate analysis, but accountability for requirements remains with authorized people and organizations.

Contemporary Practice and Best Practices

Modern teams increasingly combine product discovery with continuous delivery. Analytics, feature flags, observability, incident reports, and user research provide evidence after release and can generate new requirements. Event-driven systems and distributed services make quality attributes—consistency, resilience, latency, and observability—especially important. Privacy engineering, threat modeling, accessibility testing, and inclusive research should begin during discovery.

The following practices are broadly effective:

1. Start with outcomes and problems, not a predetermined feature list.
2. Involve diverse stakeholders and record evidence, assumptions, and decisions.
3. Use multiple elicitation methods; no single method reveals the whole domain.
4. Define terms in a shared glossary and distinguish business rules from implementation choices.
5. Make non-functional requirements measurable where measurement is appropriate.
6. Represent normal flows, exceptions, permissions, data behavior, and failure recovery.
7. Use prototypes and acceptance criteria to expose ambiguity early.
8. Prioritize transparently, including risk, dependencies, and legal obligations.
9. Maintain traceability proportionate to project risk and regulatory need.
10. Treat change as a managed learning process rather than an informal interruption.

Chapter Summary

Requirements engineering creates shared, testable understanding between stakeholders and software teams. It includes inception, elicitation, analysis, negotiation, specification, validation, and management. Requirements may describe business outcomes, system functions, quality attributes, domain rules, or temporary transition activities. Interviews, observation, workshops, document analysis, and prototypes reveal different kinds of knowledge. Use cases explain actor-system interaction, while user stories express user value and acceptance criteria make expected behavior testable. Prioritization should be transparent and sensitive to value, risk, dependencies, effort, and mandatory obligations. Validation examines validity, completeness, consistency, feasibility, clarity, verifiability, and traceability. Baselines, versioning, impact analysis, and change control preserve integrity as the product evolves. Ethical, privacy, security, accessibility, and governance concerns must be treated as first-class requirements. AI can assist requirements work, but human verification, provenance, and accountability remain essential.

Key Terms

Requirement: A needed condition, capability, or constraint for a system or stakeholder.

Requirements engineering: The disciplined elicitation, analysis, specification, validation, and management of requirements.

Functional requirement: A behavior or service the system must provide.

Non-functional requirement: A quality, constraint, or operational condition applying to a system.

Business requirement: An organizational objective or desired outcome.

Stakeholder: A person, group, or organization that affects or is affected by the system.

Elicitation: The process of discovering requirements from people, artifacts, systems, and evidence.

Use case: A description of interactions that enable an actor to achieve a goal.

User story: A concise expression of a user capability and its benefit.

Acceptance criteria: Observable conditions that determine whether a requirement is accepted.

Prototype: An incomplete representation used to explore, communicate, or validate ideas.

Domain rule: A requirement arising from the rules or knowledge of an application domain.

Traceability: The ability to link a requirement to its sources, implementation, and verification evidence.

Baseline: An agreed version used as a reference for controlled change.

Prioritization: The process of ranking requirements for delivery or attention.

Validation: Checking whether requirements describe the right product and stakeholder need.

Verification: Checking whether requirements are expressed correctly and can be assessed.

Change control: A structured process for evaluating, approving, recording, and implementing changes.

Quality attribute: A characteristic such as security, performance, accessibility, or reliability.

Review Questions

Short Answer Questions

1. Distinguish a functional requirement from a non-functional requirement and give one example of each.
2. Why is observation useful in requirements elicitation?
3. What information should acceptance criteria provide?
4. Define requirements traceability.
5. Why should a change request include impact analysis?

Long Answer Questions

1. Explain the requirements engineering lifecycle and discuss how it operates iteratively in an agile project.
2. Compare interviews, workshops, observation, document analysis, and prototypes as elicitation techniques.
3. Explain how use cases and user stories complement one another.
4. Discuss the characteristics of a high-quality non-functional requirement, using performance or security as an example.
5. Explain how validation, baselines, and change control reduce project risk.

Analytical / Application Questions

1. A client says, “The application must be easy to use and highly secure.” Rewrite these statements as several testable requirements and identify assumptions requiring clarification.
2. A hospital portal team receives conflicting requests for anonymous access and strict identity verification. Analyze the conflict, identify affected stakeholders and risks, and propose a negotiation and decision process.
3. Design a traceability approach for an online examination system. Include at least one business objective, user requirement, functional requirement, non-functional requirement, acceptance criterion, and verification artifact.

Multiple Choice Questions with Answers

Question 1

Which activity primarily transforms stakeholder statements into structured goals, rules, dependencies, and models?

A. Analysis and negotiation

B. Deployment

C. Refactoring

D. Load testing

Correct Answer: A. Analysis and negotiation

Question 2

Which statement is a non-functional requirement?

A. The system shall allow users to reset passwords.

B. The system shall generate an invoice.

C. The system shall support keyboard-only completion of checkout.

D. The system shall store a customer address.

Correct Answer: C. The system shall support keyboard-only completion of checkout.

Question 3

What is the main purpose of acceptance criteria?

A. To select a programming language

B. To define observable conditions for accepting a requirement

C. To replace stakeholder research

D. To estimate employee salaries

Correct Answer: B. To define observable conditions for accepting a requirement

Question 4

Which elicitation method is most likely to reveal informal workarounds that users do not mention in interviews?

A. Observation

B. Source-code compilation

C. Database indexing

D. Unit testing

Correct Answer: A. Observation

Question 5

In the chapter’s scoring example, what is the score when V = 5, U = 4, R = 3, C = 4, E = 2, with equal weights?

A. 4

B. 6

C. 8

D. 16

Correct Answer: C. 8

Question 6

What does traceability connect across the software lifecycle?

A. Only source-code files

B. Requirements with sources, implementation, and verification evidence

C. Only user-interface colors

D. Employee attendance records

Correct Answer: B. Requirements with sources, implementation, and verification evidence

Question 7

Which statement best describes a baseline?

A. An agreed version used as a controlled reference

B. A temporary password for testers

C. A database backup with no version identity

D. A list of unresolved interview questions

Correct Answer: A. An agreed version used as a controlled reference

Question 8

Why can a prototype be risky if not clearly explained?

A. It always prevents accessibility testing

B. Stakeholders may mistake it for finished software

C. It cannot represent workflows

D. It eliminates the need for requirements

Correct Answer: B. Stakeholders may mistake it for finished software

Question 9

Which requirement is most verifiable?

A. The interface shall be modern.

B. The search shall be extremely fast.

C. The system shall be pleasant to use.

D. At least 95% of searches shall complete within two seconds under the agreed workload.

Correct Answer: D. At least 95% of searches shall complete within two seconds under the agreed workload.

Question 10

What should happen when a proposed requirement change affects privacy, identity verification, and liability?

A. Add it immediately without analysis

B. Delete all related requirements

C. Conduct impact analysis and obtain an appropriate decision

D. Allow the developer to decide privately

Correct Answer: C. Conduct impact analysis and obtain an appropriate decision