I have an example I can share based on the definition you give. Take a smartphone for example, focusing mainly on the touch-screen interface. Validation processes would involve making sure that the pressure exerted on the display would translate from physical data as pressure to a change in some value (say, resistance) and the phone would be able to interpret that value as a user input. Verification would involve how sensitive that input needs to be from the user's end to make sure the user is comfortable in using the touchscreen of the product. It's a difference between the Engineer's point of view and the end user's point of view in which you have to strike a delicate balance be adhering to product requirements whilst meeting customer needs.

Validation and verification as stated in the lectures are both independent procedures used to establish that the product meets specifications/requirements. Validation can be described as an external process because it is associated with the needs of the customer, while verification is necessary for compliance with regulations it can be viewed as an internal process. (This concept is described in the PMBOK book Dr. Simon suggested). Examples of medical devices that verification would be sufficient would most likely be products that meet the criteria for a 510(K). For products that have a low enough risk most of the user testing can be conducted in the lab for validation since these products that require a 510(K) would be similar to products on the market.

Although the example that I will provide is more related to electrical engineering, I hope it helps you understand verification and validation in a better way. The company I used to work for was in charge of a project involving a transformer installation. The client was interviewed by the engineer in charge of the project on what he wanted specifically and how he wanted it. Days later, the team went to install the transformer as planned. When we were done the transformer was working perfectly but the client decided at the last minute that he did not like the location of it. Although it was a lot of more work, we were forced to change its location. This product was validated because it fulfill the client’s needs, it provided enough voltage for the client’s house and the current was flowing as expected. However, this product was not verified because the client was not happy with it so the project team had to do something about it.

Similar the Roberto’s example above, I have experience with method validation and verifications in my past work experience. At the pharmaceutical company I was working at one summer, I was tasked to optimize a method my company used to separate monoclonal antibodies from unreacted starting product. About halfway through the summer, I had come up with a new method that that preformed the required task. However, it was deemed too expensive a process and I was tasked with finding a cheaper alternative. By the end of the summer, I proposed another method that was both an improvement upon the original method and more cost effective than the first alternative. This was an example of validation of a method because it achieved the overall goal of the project. However, it wasn’t initially verified due to the change in financial restrictions placed upon the task.

During one of my past internships I was part of a project where we had to program a website to monitor flooding. The verification of that project was essentially whether or not the website functioned. This consisted of learning the language, programming, debugging, and repeating the process. The validation came in the form of weekly informal meetings with the fire department that was funding the project who would eventually give us feedback on the website once it was up and running. Since this website wasn't for public market neither verification nor validation was technically necessary but our team had inadvertently gone through all the essential steps.

Most of the example above described some variation of testing as their chief form of design verification. But verification is more than this, it is making sure that the design of the device is right, i.e. it meets its required technical standards. For this, the workmanship of the product must also be scrutinized with inspections and design reviews.

Design validation, on the other hand, should test whether the right device was produced; meaning that the suture you created actually and properly closes wounds. This is why design validations for medical devices are usually accompanied with clinical trails and human factors studies.

I also touched upon this in an earlier post " Discussion Topic: To trial or not to trial."

http://blog.greenlight.guru/design-verification-and-design-validation

I agree and like all of the above examples of verification and validation for different projects. Over the summer I worked on patient specific cut guides used for total ankle replacements. Just by the name, you can tell that verification itself would not be sufficient, and there would be a substantial amount of validation. One aspect of verification was determining how to test the accuracy of the 3D printed device, as it was quite a complex geometry. For example, how do you know that the inside of the pin holes surface is smooth, and an error that occurred within printing won't prevent the pin from being inserted? The pin holes are essential for keeping the cut guides in place, so the inspection process must be very thorough. As you can imagine, there are endless tests for V&V, and no detail can be overlooked.