Verification in the SDLC: Confirming the System Meets Requirements and Design Specifications

UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 7.5 Free with a free account

Verification in the SDLC: Confirming the System Meets Requirements and Design Specifications

System Analysis and Design · Chapter 7: Implementation, Testing, and MaintenanceSection 7.5 · lesson 50 of 697 min · free with a free account

← Integration Testing: Combining Modules and Validating Their Interactions Step by StepNext lesson: Exploring the Different Types of Software Testing →

Earn 3 college credits for System Analysis and DesignRecommended for credit by NCCRS · Computer Science 390 · self-paced · one payment, lifetime access
Enroll in System Analysis and Design · $250 →Download the syllabus (PDF)

In this lesson

Confirming the system meets its requirements and design specifications.

  • Distinguish verification from validation
  • Describe reviews, walkthroughs, and inspections
  • Explain static analysis, and how it differs from dynamic testing
  • Build and read a requirements traceability matrix

Transcript

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

Implementation, Testing, and Maintenance

Verification in the SDLC

How does a team know the system it is building actually matches what was specified? That is the job of verification. This section separates verification from validation, then looks at three ways verification happens. Reviews, static analysis, and the requirements traceability matrix.

2 Different Questions

Verification vs. Validation

Verification and validation sound alike, but they ask different questions. Verification asks, are we building the product right? Does a work product conform to its own specification, whether that is a requirements document or a design? Validation, covered earlier in the course, asks, are we building the right product? Does the system meet users' real needs? Verification uses reviews, walkthroughs, inspections, and static analysis. Validation uses prototyping, user testing, and acceptance testing. Verification happens throughout development, at each deliverable. Validation typically needs a working system or prototype. And the two are independent. A system can pass verification at every stage, and still fail validation, if what was specified was never actually what users needed. Verification runs continuously. A design is verified against its requirements, and code is verified against its design.

Reviews

Walkthroughs and Inspections

Review is the general term for any structured examination of a work product, by people other than its author, checked against requirements or standards. Two specific forms of review sit at opposite ends of formality. A walkthrough is informal, and led by the author. The author walks a group of reviewers through the work, a design or a piece of code, to explain it and collect early feedback. An inspection is the most formal and rigorous form. It follows a defined process, led by a trained moderator who is not the author, with assigned roles, and checklists used to find defects systematically. The inspection process was formalized by Michael Fagan, at I B M, in the nineteen seventies. It remains the model most formal inspections still follow.

Static Analysis

Checking Without Running

Static analysis examines a work product without executing it. Most often that is source code, but it can also be a design document. The goal is to detect defects, inconsistencies, or deviations from a standard. It can be done manually, as a review that focuses specifically on static properties. Or it can be done by an automated tool, which scans code for issues like unused variables, potential null references, or style violations.

2 Kinds of Checking

Static Analysis vs. Dynamic Testing

Static analysis is best understood next to dynamic testing, which does run the system. Static analysis catches things like coding standard violations, potential null references, unreachable code, and structural inconsistencies. It examines the work product directly, rather than depending on one particular execution path being run. Dynamic testing catches logic bugs that only appear during execution, performance issues, and runtime failures. Static analysis can start as soon as code, or even a design, exists. Dynamic testing needs a running, executable version. So because static analysis needs nothing running, it tends to be cheaper and earlier. It catches a different class of problem, before the system is ever executed.

Figure 7.1

The Requirements Traceability Matrix

The third verification tool is the requirements traceability matrix, or R T M. It links each requirement to the design element, the code module, and the test case that implement and verify it. That lets a team check two directions of tracing at once. Forward tracing runs from requirement, through design and code, to test. It confirms that every requirement was actually built, and tested. Backward tracing runs the other way, from test and code back to the requirement. It confirms that every design, code, and test item exists for a real reason.

An RTM in Practice

Reading the Matrix Row by Row

Here is what an R T M looks like in practice, with two rows. Requirement one says the system shall lock a user account after five failed login attempts. It traces to section three point two of the authentication module specification, to the lock account method in the auth service, and to test case fourteen. Requirement two says the system shall send a confirmation email within five seconds of registration. It traces to section two point one of the notification module specification, to the send confirmation method in the notification service, and to test case twenty-seven. Every row is a complete chain. From what was asked, to how it was designed, to how it was built, to how it was proven.

2 Directions

What Each Direction Catches

Each direction of tracing catches a different problem. Forward tracing catches a requirement that was approved, but never actually built or tested. That is a gap in delivery. Backward tracing catches the opposite problem. A piece of design, code, or a test case that exists, but does not trace back to any approved requirement. So what does a code module with no requirement behind it usually mean? It typically signals scope that crept into the system, without ever being formally requested or approved.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Verification asks whether the product was built right. Validation asks whether the right product was built. A walkthrough is an informal, author-led review, for early feedback. An inspection is a formal review, with a trained moderator, defined roles, and checklists. Static analysis examines a work product without executing it. A requirements traceability matrix links requirements to design, code, and tests. Forward tracing asks, was it built? Backward tracing asks, does it belong?

Key Takeaways

What to Carry Forward

To pull this together. Verification asks whether the product was built right, against its own specification. Validation asks whether the right product was built, against real user needs. Walkthroughs are informal and author-led. Inspections are the most formal, with a trained moderator, defined roles, and checklists. Static analysis examines a work product without running it, catching a different class of defect, earlier and more cheaply than dynamic testing. And a requirements traceability matrix links requirements to design, code, and tests, supporting forward tracing, was it built, and backward tracing, does it belong.

About System Analysis and Design at UPI Study

System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance 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 System Analysis and Design with UPI Study

From business problem to working systemSystem Analysis and Design teaches how analysts study a business need and turn it into a system design: requirements, UML and data-flow models, interface and database design, implementation and project management. It is a core course in information systems and IT 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

System Analysis and Design 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 Verification in the SDLC: Confirming the System Meets Requirements and Design Specifications

What is the difference between verification and validation in software engineering?
Verification asks whether the product is being built right, while validation asks whether the right product is being built. Verification checks each work product against its own specification, using reviews, walkthroughs, inspections, and static analysis throughout development. Validation checks the system against users' real needs, using prototyping, user testing, and acceptance testing. A system can pass verification at every stage and still fail validation.
What is the difference between a walkthrough and an inspection?
A walkthrough is an informal review led by the author, while an inspection is a formal review led by a trained moderator who is not the author. In a walkthrough, the author explains a design or code to reviewers to gather early feedback. An inspection follows a defined process with assigned roles and checklists to find defects systematically, a model formalized by Michael Fagan at IBM in the 1970s.
How does static analysis differ from dynamic testing?
Static analysis examines code or a design without running it, while dynamic testing executes the system. Static analysis, manual or automated, catches issues such as coding standard violations, unused variables, potential null references, and unreachable code. Because nothing has to run, it can start earlier and tends to be cheaper. Dynamic testing finds logic bugs, performance issues, and runtime failures that appear during execution.
What is a requirements traceability matrix used for?
A requirements traceability matrix, or RTM, links each requirement to the design element, code module, and test case that implement and verify it. Forward tracing, from requirement to test, reveals requirements that were approved but never built or tested. Backward tracing, from code and tests back to requirements, reveals items with no approved requirement behind them, which typically signals scope creep.

About the System Analysis and Design course

How many college credits is System Analysis and Design?
System Analysis and Design (Computer Science 390) 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 System Analysis and Design cost and what is included?
$250, paid once, with lifetime access: all 69 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 System Analysis and Design take?
It is self-paced with no deadlines. The 69 lessons total about 9 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 System Analysis and Design.

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

Enroll in System Analysis and Design →Download the syllabusEvery course with PRO →
System Analysis and Design
3 credits · NCCRSEnroll →