Validation in Practice: Prototyping, Surveys, Document Reviews, and User Analysis

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

Validation in Practice: Prototyping, Surveys, Document Reviews, and User Analysis

System Analysis and Design · Chapter 4: Requirements Validation, Modeling, and UMLSection 4.1 · lesson 24 of 699 min · free with a free account

← BPMN in Practice: Symbols, Swimlanes, Gateways, and Event Notation for Mapping ProcessesNext lesson: Defining System Boundaries with Context Diagrams →

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

Prototypes, surveys, document reviews, user analysis, and acceptance criteria.

  • Explain validation, and how it differs from verification
  • Compare throwaway vs. evolutionary, and low- vs. high-fidelity prototyping
  • Use confirmation surveys and checklist reviews to test requirements
  • Use personas, task analysis, and Given/When/Then acceptance criteria

Transcript

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

Requirements Validation, Modeling, and UML

Validation in Practice

Gathering requirements is only half the job. An analyst also has to confirm that what was gathered is actually correct, before the team commits time and money to building it. This section covers five practical techniques for that confirmation step. Prototyping, confirmation surveys, document reviews, user analysis, and acceptance criteria. First, though, we need to be precise about what validation is, because it is easily confused with something else.

The Purpose

Validation vs. Verification

Requirements validation confirms that the documented requirements actually reflect what stakeholders need. And it does that before any design or coding begins. It answers a different question from verification. Validation asks, are we building the right system? It checks the documented requirements against real stakeholder needs. Verification asks, are we building the system right? It checks the finished software against the documented requirements. You can pass verification perfectly, and still fail validation, if the requirements were wrong to begin with. In that case, the team has built exactly what was written down. It just was not what anyone needed. That is why validation happens early, while requirements are still on paper, when a misunderstanding is cheap to correct.

Technique 1: Prototyping

2 Independent Dimensions

The first technique is prototyping. A prototype is a working model of part of the system, built to gather feedback before committing to a full build. Prototypes vary along two independent dimensions. The first is what happens to them afterward. A throwaway prototype is built quickly to explore an idea, then discarded once feedback is gathered. None of its code or design is reused. An evolutionary prototype is refined across iterations until it becomes the final product. So early technical choices carry forward. The second dimension is fidelity, meaning how closely it resembles the finished system. A low-fidelity prototype is a paper sketch or a basic wireframe. It is fast and cheap to change. A high-fidelity prototype closely matches the finished look, feel, and interactions. But it costs more to build and to revise.

Figure 1

4 Prototyping Approaches

Because the two dimensions are independent, they combine into four approaches. Low fidelity and throwaway. Paper sketches used once, to explore several layout ideas with users, then discarded. High fidelity and throwaway. A polished, clickable mockup built to win stakeholder buy-in, then set aside once approved. Low fidelity and evolutionary. A basic wireframe framework that is gradually filled in, and refined into the shipped product. And high fidelity and evolutionary. A realistic prototype built in the actual technology stack, and incrementally refined into the final release. Choosing well matters. An evolutionary prototype carries its early technical choices into the product, good or bad. A throwaway prototype is free to cut corners, precisely because it will be discarded.

Technique 2

Confirmation Surveys

The second technique is the confirmation survey. It asks stakeholders to rate how well a documented requirement matches their actual need. Usually that is a short rating scale, rather than an open-ended question. Here are some sample statements, each rated from strongly disagree to strongly agree. This requirement describes my daily workflow accurately. This requirement is missing something important to my work. And, I would be satisfied if the system worked exactly as this requirement describes. Because a survey can reach many stakeholders at once, it suits large, or geographically spread, groups. Notice the second statement. It invites stakeholders to report what is missing, not just to approve what is there.

Technique 3

Checklist-Driven Document Reviews

The third technique is a requirements document review. It is a structured, checklist-driven reading of the requirements document, by people other than the person who wrote it. That is often a mix of analysts, developers, and stakeholders. The checklist keeps the review consistent, and keeps reviewers from simply skimming for typos. Completeness asks whether the document covers every function and constraint the stakeholders described. Clarity asks whether two different readers could interpret any requirement in two different ways. Testability asks whether each requirement can be checked objectively, once the system is built. Consistency asks whether any two requirements contradict each other. Feasibility asks whether it can realistically be built, within the time, budget, and technology. And traceability asks whether each requirement traces back to a specific stakeholder need.

Technique 4: User Analysis

Personas: A Realistic User, Not "The User"

The fourth technique is user analysis. Requirements often describe what a system should do, without capturing who will actually use it, and how. Personas and task analysis fill that gap. A persona is a fictional but realistic profile representing one group of actual users. It is built from research, not guesswork. Meet Maria Alvarez, a returning customer, aged thirty-four. Her goal is to reorder household items quickly, without re-entering information she has already given the site. Her frustrations are long checkout forms, and re-entering her shipping address on every order. She is comfortable with everyday apps, but will not tolerate a confusing or slow checkout. Now a shipping requirement can be checked against Maria's goals, instead of an abstract idea of the user. A requirement that makes her re-enter her address on every order fails her, even if it passes every other check.

Figure 3

Task Analysis

Task analysis grounds requirements in what users actually do. It breaks a user's goal down into the specific sequence of actions needed to accomplish it. Here, the goal is to complete an online purchase. That breaks into browsing products, adding items to the cart, entering shipping and payment, and confirming the order. And entering shipping and payment breaks down one level further. Enter a shipping address, select a shipping method, and enter payment details. Now compare this breakdown against the documented requirements. It often reveals a step the requirements never mentioned at all. For example, if no requirement mentions selecting a shipping method, the gap shows up here, on paper, not after launch.

Technique 5

Acceptance Criteria: Given, When, Then

The fifth technique is acceptance criteria. These are the specific, testable conditions a requirement must satisfy before it is considered complete. They turn a general statement of need into something a reviewer can check off, as met or not met. A common format is given, when, then. Take the requirement, as a customer, I want to filter search results by price, so that I can find items within my budget. Given a customer is viewing a page of search results. When the customer sets a minimum and maximum price, and applies the filter. Then only results priced within that range are displayed, and the count of matching results updates. Notice that the last line can be tested, precisely. That is what makes the requirement verifiable later on.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Validation confirms that requirements reflect what stakeholders actually need. Verification confirms that the software matches the requirements. A throwaway prototype is discarded after feedback. An evolutionary prototype is refined into the final product. A confirmation survey uses rating scales to check requirements against stakeholder needs. A persona is a fictional, research-based profile of one group of users. Task analysis breaks a user's goal into the specific sequence of actions needed. And acceptance criteria are the testable conditions a requirement must meet to be complete.

Key Takeaways

What to Carry Forward

To pull this together. Validation confirms requirements are right before building. Verification confirms the built system matches them. Prototypes vary by disposability and by fidelity, and the two combine into four common approaches. Confirmation surveys check requirements at scale. Checklist reviews catch gaps in completeness, clarity, testability, consistency, feasibility, and traceability. Personas ground requirements in a realistic user, and task analysis in that user's actual steps. And given, when, then acceptance criteria turn a general requirement into something a reviewer can verify.

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 Validation in Practice: Prototyping, Surveys, Document Reviews, and User Analysis

What is requirements validation, and when does it happen?
Requirements validation confirms that the documented requirements actually reflect what stakeholders need, and it happens before any design or coding begins. It asks whether the team is building the right system, unlike verification, which later checks the finished software against those requirements. A system can pass verification perfectly and still fail validation if the requirements were wrong, which is why validation happens early, when misunderstandings are cheap to fix.
What is the difference between a throwaway prototype and an evolutionary prototype?
A throwaway prototype is built quickly to explore an idea and then discarded once feedback is gathered, while an evolutionary prototype is refined across iterations until it becomes the final product. Because none of a throwaway prototype's code is reused, it is free to cut corners. An evolutionary prototype carries its early technical choices, good or bad, into the finished system, so those choices deserve more care.
What is a persona in requirements analysis?
A persona is a fictional but realistic profile representing one group of actual users, built from research rather than guesswork. It typically describes the user's goals, frustrations, and comfort with technology. For example, a returning shopper who wants to reorder quickly and hates re-entering a shipping address lets analysts test a requirement against a concrete user. A requirement that forces her to retype her address fails her, even if it passes other checks.
How do you write acceptance criteria using Given, When, Then?
Given, When, Then acceptance criteria state the starting situation, the action taken, and the expected testable result. For a price filter requirement: given a customer is viewing search results, when the customer sets a minimum and maximum price and applies the filter, then only results within that range are displayed and the count of matching results updates. The precise final line is what makes the requirement verifiable later.

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 →