2 Requirements Engineering Free Online FlashCards

What is requirements engineering?

Requirements engineering is the systematic work of discovering, analyzing, recording, prioritizing, and checking what a software system must do and the constraints under which it operates.

What is requirements elicitation?

Elicitation uncovers stakeholder needs, expectations, constraints, and assumptions from people and other sources.

What does requirements analysis do?

Analysis establishes scope and context, classifies needs, finds gaps and conflicts, assesses feasibility and risk, and decomposes and traces requirements.

What factors can guide requirement prioritization?

Teams can weigh value, urgency, risk reduction, cost and effort, and dependencies.

What information commonly belongs in a requirements specification?

A specification commonly records scope, stakeholders, assumptions, constraints, interfaces, functional and quality requirements, and acceptance or verification information.

How do requirements validation and verification differ?

Validation asks whether requirements describe the system stakeholders need—the right system. Verification checks whether requirements are well formed and the product conforms to them—the system built right.

Why is requirements engineering usually iterative?

They are iterative because stakeholders, operating environments, and understanding can change, requiring teams to revisit and refine requirements.

How can scenarios reveal tacit stakeholder needs?

Scenarios make system behavior concrete, helping stakeholders reveal needs that broad questions may miss, such as availability, expiration, and notifications.

Why should teams identify whose needs are represented?

Stakeholders can have different or conflicting goals. Teams should identify whose needs are represented and whose may be missing.

What qualities make an individual requirement useful?

A useful requirement is clear, unambiguous, necessary, feasible, and verifiable.

How can a vague speed requirement be made verifiable?

Replace vague wording with measurable conditions: for example, results appear within 2 seconds for 95% of searches with up to 1,000 concurrent users.

What should a requirement describe instead of prescribing a design?

It should describe the required outcome rather than unnecessarily prescribing how the system must be designed.