Home › CPRE FL › Practice questions › Fundamental Principles of Requirements Engineering
CPRE FL · IREB · Fundamental Principles of Requirements Engineering · Bank updated 2026-10-15

CPRE FL practice questions: Fundamental Principles of Requirements Engineering

5 free questions from 12 on this area · answer and explanation for each · no sign-up

These 5 questions come from the Fundamental Principles of Requirements Engineering section of our CPRE FL bank (12 questions on this area, which carries 8% of the real exam). Every question is original, with the correct answer explained and linked to the source it is drawn from.

Try 6 free CPRE FL questions → All CPRE FL sample questions

Free: 6 questions in study mode, no card. All 12 Fundamental Principles of Requirements Engineering questions and the full CPRE FL bank: $15 one-time.

1/5 · Fundamental Principles of Requirements Engineering · easy
A project manager tells the requirements engineer: 'Only the client who signed the contract counts as a stakeholder for elicitation — everyone else's opinion is irrelevant.' Which fundamental RE principle does this statement most directly contradict?
AThe evolution principle, because it assumes requirements will never change after the contract is signed.
BThe separation of concerns principle, because it merges business and technical requirements into a single document.
CThe stakeholders principle, because requirements engineering must consider the needs of everyone who influences or is affected by the system, not only the contracting party.
DThe context principle, because it ignores the technical environment in which the system will operate.
Answer: C. The stakeholders principle recognizes that requirements originate from a broad set of parties — end users, operators, regulators, and others — not just the party who formally signs a contract. Restricting elicitation to only the contracting client risks missing important needs and constraints, leading to an incomplete or unusable system. Source: IREB CPRE Foundation Level Syllabus v3.3.0 (2026) + CPRE FL Handbook — Fundamental Principles of Requirements Engineering
2/5 · Fundamental Principles of Requirements Engineering
A team documents functional requirements for a checkout system but never describes how the external payment gateway behaves when it responds slowly, even though slow gateway responses directly affect what the checkout system must do (e.g., show a waiting state, allow retry). Which fundamental RE principle is most directly being neglected?
AValidation, because the requirements specification was never reviewed by someone from the payment provider's team.
BContext, because understanding the system's environment and its interactions with neighboring systems is necessary to derive complete and correct requirements.
CStakeholders, because the payment provider never signed a contract with the project team.
DSeparation of concerns, because payment processing and checkout functionality should never appear together in the same requirement.
Answer: B. The context principle requires that requirements engineers explicitly consider the system boundary and its interactions with the surrounding environment, including external systems. Omitting the payment gateway's behavior means a relevant part of the context was ignored, risking incomplete or incorrect requirements for the checkout system. Source: IREB CPRE Foundation Level Syllabus v3.3.0 (2026) + CPRE FL Handbook — Fundamental Principles of Requirements Engineering
3/5 · Fundamental Principles of Requirements Engineering · hard
A team writes a requirements specification, has it internally checked for internal consistency, correct grammar, and adherence to a document template, and then proceeds directly to implementation without any further involvement of stakeholders. Which aspect of the 'validation' principle has this team most likely neglected?
AThey failed to confirm with the stakeholders that the documented requirements reflect their actual needs and expectations.
BThey failed to trace every requirement to a corresponding test case in a test management tool before implementation started.
CThey failed to have an independent reviewer from outside the team verify the specification against the writing rules.
DThey failed to estimate the implementation effort of each requirement with the stakeholders before starting development.
Answer: A. Validation is distinct from verification: verification checks that a specification is internally correct and consistent (e.g., against templates or writing rules), whereas validation checks that the specification actually captures what stakeholders truly need — 'building the right system.' Skipping stakeholder involvement after internal review leaves the risk that requirements are well-formed but wrong. Source: IREB CPRE Foundation Level Syllabus v3.3.0 (2026) + CPRE FL Handbook — Fundamental Principles of Requirements Engineering
4/5 · Fundamental Principles of Requirements Engineering · easy
The IREB CPRE Foundation Level glossary defines the term "requirement" with three related parts. Which statement correctly reflects that definition?
AA requirement is a formally documented and approved statement of a needed condition or capability; a stakeholder need that has not yet been written down is still an input to requirements engineering, not a requirement.
BA requirement is a condition or capability that a stakeholder needs to solve a problem or achieve an objective, or a documented representation of such a need; conditions imposed on the system by a contract or standard are handled as constraints, not as requirements.
CA requirement is a condition or capability that has been negotiated and formally agreed upon by all relevant stakeholders and recorded in the specification together with its source, priority and acceptance criteria.
DA requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective, a condition or capability a system must meet to satisfy an imposed document such as a standard or contract, or a documented representation of either.
Answer: D. The IREB glossary adopts a three-part definition of "requirement": a stakeholder need, a condition imposed by a contract/standard, and the documented representation of either. This prevents narrowing the term to only formally written or already-agreed statements — a frequent misconception among newcomers to RE. Source: the IREB CPRE Foundation Level Syllabus v3.3.0 — Fundamental Principles of Requirements Engineering
5/5 · Fundamental Principles of Requirements Engineering
During elicitation for an online banking system, a business analyst lists the bank's fraud-detection regulations and the behaviour of a partner payment gateway as part of the "system context", even though neither is hardware or software the bank itself operates. A colleague objects that only physical or technical elements belong in the system context. Which statement best resolves this disagreement?
AThe colleague is correct: the system context is defined strictly by the physical and technical environment in which the system operates, so regulations and partner behaviour belong to the requirements themselves, not the context.
BBoth are partly right: regulations belong to the system context, but the partner payment gateway is inside the system boundary because the banking system directly depends on it to function.
CThe colleague is mistaken: the system context comprises everything relevant to the system's requirements that lies outside the system boundary, which can include regulations, business rules, and external systems, not only physical or technical elements.
DNeither is correct: the system context is not part of requirements engineering at all, since it only becomes relevant once the system is in operation and being maintained.
Answer: C. The syllabus defines the system boundary as the line separating the system under consideration from everything else, and the system context as the relevant part of that "everything else" — including regulatory, organizational, and neighbouring-system elements — that influences or is influenced by the system's requirements. Restricting context to only physical/technical surroundings is a common but incorrect simplification. Source: the IREB CPRE Foundation Level Syllabus v3.3.0 — Fundamental Principles of Requirements Engineering
Try 6 more free CPRE FL questions → See the whole CPRE FL bank

Other CPRE FL areas

The same kind of free sample for every other section of the CPRE FL bank:

Work Products and Documentation Practices45 qPractices for Requirements Elaboration25 qProcess and Working Structure12 qIntroduction and Overview of Requirements Engineering11 qTool Support20 qManagement Practices for Requirements20 q

Practise CPRE FL with instant feedback

6 free questions in study mode · no card · full CPRE FL bank with area filters and the error log: $15 one-time · no dumps, no ads.

Start CPRE FL free →
Read next
IREB CPRE Foundation Level: Format, Cost and a Study Plan CPRE FL: 45 questions, 75 minutes, 70% to pass, no prerequisites, valid for life. Who sets the price, how retakes work, and a four-week study plan.
ExamDeck is an independent study tool, not affiliated with, endorsed by, or sponsored by IREB. CPRE FL and related marks are trademarks of their respective owners, used for identification only. Exam facts checked against official IREB materials (as of August 2026); always confirm current details with the vendor before booking.