2 Requirements Engineering

Purpose and iterative process

Requirements engineering turns stakeholder needs into an agreed, manageable basis for building and evaluating software. It includes discovering, analyzing, recording, prioritizing, and checking what the system must do and the constraints under which it must operate.

A requirement expresses a stakeholder need precisely enough to guide development and evaluation. Since stakeholders, environments, and understanding can change, requirements work is usually iterative rather than a one-time phase.

Eliciting stakeholder needs

Elicitation uncovers needs, expectations, constraints, and assumptions from people and other sources. Relevant stakeholders may include users, customers, operators, maintainers, developers, business owners, and regulators. Different groups can have conflicting goals, so teams need to identify whose needs are represented and whose may be missing.

Common techniques include:

• Interviews to explore individual goals, workflows, and problems.

• Workshops to build shared understanding and resolve disagreements.

• Observation to learn how work is actually performed, including informal workarounds.

• Surveys to collect input from many stakeholders.

• Document and system analysis to identify existing rules, interfaces, and constraints.

• Scenarios, prototypes, and storyboards to help stakeholders respond to concrete examples of system behavior.

For a library app, asking “What do you need?” may produce broad answers. Walking through a scenario—finding a book, reserving it, receiving a notice, and collecting it—can reveal needs concerning availability, expiration, and notifications. Combining techniques helps expose tacit needs and resolve incomplete or inconsistent statements.

Analyzing scope and quality

Analysis turns raw stakeholder input into a coherent, feasible, and testable set of requirements. It involves several connected tasks:

1. Define scope and context. Establish what the system will and will not do, who will use it, and which external systems it must interact with.

2. Classify needs. Distinguish functional requirements, which describe services or behavior; quality requirements, such as usability, security, or reliability; interfaces; and constraints. State quality requirements in measurable, contextual terms where possible.

3. Find gaps and conflicts. Look for missing cases, inconsistent goals, ambiguous terms, duplicates, and assumptions that need confirmation.

4. Assess feasibility and risk. Consider technical, operational, legal, schedule, and cost constraints. Use prototypes or analysis to investigate uncertainty.

5. Decompose and trace. Break broad needs into appropriately detailed requirements and record how each relates to a stakeholder need or a higher-level requirement.

A useful individual requirement is clear, unambiguous, necessary, feasible, and verifiable. Vague words such as fast, easy, or usually should be avoided unless they are defined. For example, replace “The app shall load quickly” with “The app shall display the search results within 2 seconds for 95% of searches when the service has up to 1,000 concurrent users.”

A requirement should describe an outcome rather than prescribe a design unnecessarily.

Prioritizing requirements

Projects usually have more candidate requirements than available time or resources. Prioritization makes trade-offs explicit. Stakeholders and the team can assess:

• Value: benefit to users or the organization.

• Urgency: deadline, regulatory, or operational need.

• Risk reduction: whether the requirement addresses significant harm or uncertainty.

• Cost and effort: expected implementation and maintenance work.

• Dependencies: whether other requirements must be delivered first.

MoSCoW ranks requirements as Must, Should, Could, or Won’t for now, with the reason for each decision explained. For example, account recovery may be a “Must” if users otherwise lose access, while profile themes may be a “Could.” The category alone is not a substitute for discussion. Priorities should be reviewed as evidence and constraints change; more formal methods compare value, cost, risk, and dependencies.

Documenting and tracing requirements

Requirements should be recorded in a form that stakeholders, developers, testers, and maintainers can understand and use. Depending on project size and risk, teams may use a structured specification, a backlog, models, or a combination. A specification commonly identifies system scope, stakeholders, assumptions, constraints, interfaces, functional requirements, quality requirements, and acceptance or verification information.

Give each requirement a stable identifier. Where useful, record its source, rationale, priority, status, owner, dependencies, and planned verification method. Traceability links needs to requirements and requirements to design, implementation, and tests. It helps teams assess the effects of a change and identify uncovered needs.

A structured requirement can state behavior, operating conditions, and a measurable success threshold:

REQ-12 — Search response time: Given a catalog of up to 100,000 items and 500 concurrent users, the system shall return search results within 2 seconds for at least 95% of searches during a 15-minute test.

In an agile backlog, a user story may express the goal, while acceptance criteria provide the precise conditions used to assess completion.

Validating stakeholder needs

Requirements validation asks whether documented requirements describe the system stakeholders actually need—the right system. It can include stakeholder reviews, walkthroughs, scenario analysis, prototypes, simulations, and tests of acceptance criteria.

For each requirement, consider whether it addresses a real, authorized need; is clear, consistent with other requirements, and within scope; can be demonstrated or measured; addresses important operating conditions and exceptional cases; and gives stakeholders a basis for agreeing on successful fulfillment.

For the search-response requirement, stakeholders can validate whether the response-time target and load conditions reflect real use. Planning how requirements will be checked early makes vague or impractical statements easier to detect before implementation.

Distinguishing verification from validation

Verification checks whether requirements are well formed and whether a product conforms to specified requirements—the system built right. This differs from validation, which asks whether the requirements describe the system stakeholders need.

For the search-response requirement, a test can later verify the measured response time. Defining verification methods and conditions early supports precise, checkable requirements and helps reveal statements that cannot be assessed as written.

Putting the activities together

Requirements engineering brings together elicitation, analysis, prioritization, documentation, and validation. Teams gather needs from multiple sources, assess scope, feasibility, consistency, and testability, make trade-offs against value and constraints, document requirements with identifiers and traceability, and check them with stakeholders. Repeating these activities as understanding changes reduces ambiguity and supports better development decisions.

• Quality requirement