Checking That Requirements Are Right: Validation Techniques

UPI Study › Courses › Software Engineering › Free lessons › Lesson 11.1 Free with a free account

Checking That Requirements Are Right: Validation Techniques

Software Engineering · Chapter 11: Requirements Validation, Dependability, and Formal MethodsSection 11.1 · lesson 72 of 1037 min · free with a free account

← UI Design in Practice: Real-World Software ExamplesNext lesson: What Makes a System Dependable? Core Properties and Goals →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Validation techniques: reviews, traceability, and acceptance criteria.

  • Distinguish verification from validation
  • Explain requirements reviews, and what reviewers look for
  • Explain forward and backward traceability checking
  • Use acceptance criteria to validate with a stakeholder

Transcript

Everything said in the video, section by section (806 words). Read along, or search it.

Requirements Validation, Dependability, and Formal Methods

Checking That Requirements Are Right

A system can match its requirements perfectly, and still be the wrong system. This section covers the practical, people-centered techniques for catching that gap early. Requirements reviews, traceability checking, and acceptance criteria.

Built Exactly as Specified

Verified, but Not Validated

A team builds a shipping-cost calculator exactly as specified. Every requirement is met precisely, and the code passes every test written against it. Then the customer opens the finished feature, and says, this is not what we needed at all. We wanted the cost estimate before checkout, not after. The team verified their work flawlessly. They never validated it.

Figure 1

2 Different Questions

Verification and validation ask two genuinely different questions. Verification asks whether the system conforms to its specification. Are we building the product right? Validation asks whether the specification, and the system built from it, actually satisfies what the stakeholder needs. Are we building the right product? Passing one does not guarantee passing the other. A system can be perfectly verified, matching its specification exactly, while still being invalid, because the specification never matched the real need.

Table 1

Verification vs. Validation

Here are the two side by side. Verification asks whether the system matches the specification. Validation asks whether it matches the real need. Verification checks against the requirements as written. Validation checks against the stakeholder's actual intent. And verification typically happens during and after construction. Validation belongs early, and repeatedly, as requirements take shape.

Requirements Reviews

Examining Requirements Together

A requirements review is a structured session where stakeholders and the team examine a set of requirements together. They look for errors, ambiguities, omissions, and conflicts, before significant effort is committed. Mixing technical and business reviewers helps. A reviewer checks each requirement against the writing-quality characteristics, like clarity and testability. But a reviewer also asks a validation question those characteristics cannot answer. Does this actually reflect what the stakeholder meant? Reviewers also look for conflicts between requirements, and for anything obviously missing. A review produces a list of issues to resolve, not a redesign.

Traceability Checking

Checking the Links, Both Ways

Traceability checking follows the links between requirements and everything else, and confirms they are actually complete. Forward traceability asks whether every requirement leads to something built and tested. A gap reveals a requirement that was written, but silently dropped. Backward traceability asks whether every feature traces back to an actual requirement. A gap reveals scope that grew, without anyone genuinely asking for it. Complete traceability links every requirement to what implements it, and why it exists.

Acceptance Criteria

Does "Done" Mean What They Mean?

Acceptance criteria are the specific, testable conditions that must hold for a requirement to count as satisfied. Take a vague requirement. The dashboard should load quickly. Specific criteria might say the main view renders within two seconds on a typical connection, for at least ninety-five percent of page loads. Checking acceptance criteria then asks the stakeholder directly. Not whether the criteria are clear, which a review already settled. But whether meeting them is genuinely what they want. If it loads in two seconds nineteen times out of twenty, is this requirement met for you?

Table 4

Ready to Build? The Shipping Calculator

These three techniques work together, as a practical readiness check before building. Go back to the shipping-cost calculator. A requirements review could have asked directly whether the estimate comes before or after checkout. A traceability check could have traced the requirement back to a vague note, one nobody had confirmed with the stakeholder. And an acceptance criteria check could have proposed a specific scenario, which the stakeholder would have disagreed with immediately. Any one of the three would likely have surfaced the problem before anything was built.

Apply It

A Review Alone Isn't Enough

Let's apply that. A team runs a thorough requirements review, and fixes several ambiguities. They skip acceptance criteria checking, because everyone agreed the wording was clear. Later, stakeholders disagree sharply about whether a delivered feature satisfies its requirement. What was missed? Clear wording can still leave the actual threshold of done undecided between the stakeholder and the team. Acceptance criteria checking is what forces that specific agreement, before delivery rather than after.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Verification checks whether a system conforms to its specification. Validation checks whether the specification, and the system built from it, satisfies the real need. A requirements review is a structured session examining requirements for errors, ambiguities, omissions, and conflicts. Forward traceability confirms every requirement has something built and tested against it. Backward traceability confirms every feature traces back to a requirement. And acceptance criteria are the specific, testable conditions that must hold for a requirement to count as satisfied.

Key Takeaways

What to Carry Forward

To pull this together. Verification asks whether a system matches its specification. Validation asks whether the specification matches the real need. A system can pass one and fail the other. Requirements reviews check writing quality, and whether requirements reflect what stakeholders meant. Forward traceability catches dropped requirements, and backward traceability catches features nobody asked for. Acceptance criteria checking confirms, with the stakeholder, what done actually means. And these are people-centered techniques. The formal, mathematical methods come later.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Checking That Requirements Are Right: Validation Techniques

What is the difference between verification and validation of requirements?
Verification asks whether the system conforms to its specification, often summed up as building the product right. Validation asks whether the specification, and the system built from it, meets what stakeholders actually need, or building the right product. A system can pass verification and still fail validation, as when a shipping-cost calculator built exactly to spec shows the estimate after checkout when the customer wanted it before.
What happens in a requirements review?
A requirements review is a structured session in which stakeholders and the team examine a set of requirements for errors, ambiguities, omissions, and conflicts before significant effort is committed. Mixing technical and business reviewers helps. Reviewers check qualities like clarity and testability, but also ask whether each requirement reflects what the stakeholder meant. The output is a list of issues to resolve, not a redesign.
What is the difference between forward and backward traceability?
Forward traceability checks that every requirement leads to something built and tested; a gap reveals a requirement that was written but silently dropped. Backward traceability checks that every feature traces back to an actual requirement; a gap reveals scope that grew without anyone genuinely asking for it. Complete traceability links each requirement to what implements it and to why it exists.
How do acceptance criteria help validate requirements with stakeholders?
Acceptance criteria turn a vague requirement into specific, testable conditions, then ask the stakeholder whether meeting them is really what they want. "The dashboard should load quickly" might become "the main view renders within two seconds on a typical connection for at least 95 percent of page loads." Clear wording alone can leave the threshold of done undecided, so this check forces agreement before delivery.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →