Validation includes activities such as requirements modelling, prototyping and user evaluation.
In a traditional phased software lifecycle, verification is often taken to mean checking that the products of each phase satisfy the requirements of the previous phase.
I thought of this architectural axiom when I read a BA Times article “Dazzle ‘em With Your Documentation Style! In architecture terms, the article addressed the “form” of business requirements document (BRD).
Agreeing with the authors on enhancing the “form” of the BRD, I almost wrote a comment to that effect.
I’ll draw a better picture when I’ve finished analyzing the data from my field studies of practices used at climate labs.
Many different V&V tools are already in use at most climate modelling labs, but there is room for adding more tools to the toolbox, and for sharpening the existing tools ( are the subjects of my current research).
Much has been said about verifying and validating the solution during testing at the end of a project. Essentially in this model, the systems analyst verifies the solution to the specification followed by the business analyst/stakeholders validating the solution to the documented and approved requirements (assumes a waterfall approach).Validation is relegated to just the begining and ending of the project: requirements analysis and acceptance testing.This view is common in many software engineering textbooks, and is misguided.It assumes that the customer’s requirements can be captured completely at the start of a project, and that those requirements will not change while the software is being developed.In practice, the requirements change throughout a project, partly in reaction to the project itself: the development of new software makes new things possible.
(from Software Verification and Validation: Its Role in Computer Assurance and Its Relationship with Software Project Management Standards, by Dolores R. Fujii, NIST Special Publication 500-165) Having thus carefully distinguished the two terms, my advice to V&V practitioners was then to forget about the distinction, and think instead about V&V as a toolbox, which provides a wide range of tools for asking different kinds of questions about software.