---
title: "Prototype model and when to use it"
subject: "Software Engineering"
chapter: 1
key: "semester_5/software_engineering:prototype-model"
source: https://www.bctengineer.com/q/semester_5/software_engineering/prototype-model
site: BCT Engineering
---

# Prototype model and when to use it

Software Engineering · Chapter 1: Software Process and requirements

- Asked in: 2070 Chaitra (old course), 4+6 marks
- Video: [SE 8 : Prototyping Model | Complete Explanation with Example](https://www.youtube.com/watch?v=dpiClb7S9Jc) — CS & IT Tutorials by Vrushali 👩‍🎓
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/prototype-model
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1

## Question

What is a prototype model? Under what circumstances is it beneficial to construct a prototype model?

## Short answer

A prototype model builds a quick, incomplete working version to explore requirements, evaluates it with users, and refines until requirements are clear, using either throwaway or evolutionary approaches. It is beneficial when requirements are unclear, user interface is critical, the system is novel, technical feasibility is uncertain, risk of building the wrong system is high, users can participate closely, or feasibility must be demonstrated early.

## Answer

#### Prototype model
A **prototype** is an early, working but incomplete version of a software system, built quickly and cheaply to demonstrate concepts, try out design options and find out more about the requirements. The **prototyping model** is a process model in which such a prototype is built, evaluated by the customer and refined repeatedly until the requirements are clear.

```text
      +------------------------+
      | Gather basic           |
      | requirements           |
      +-----------+------------+
                  v
      +------------------------+
      | Quick design           |
      +-----------+------------+
                  v
      +------------------------+
      | Build prototype        |<------+
      +-----------+------------+       |
                  v                    |
      +------------------------+       |
      | Customer evaluation    |       |
      +-----------+------------+       |
                  v                    |
      +------------------------+  no   |
      | Requirements clear?    |-------+
      +-----------+------------+  refine
                  | yes
                  v
      Engineer / build final product
```

Steps:
1. **Requirements gathering**: developer and customer define overall objectives and known requirements; unclear areas are noted.
2. **Quick design**: focuses on visible aspects such as user interface and input/output formats.
3. **Build prototype**: using fast tools (UI builders, scripting languages, reusable components), ignoring efficiency and full error handling.
4. **Customer evaluation**: users try the prototype and give feedback.
5. **Refinement**: the prototype is changed and evaluated again until requirements are understood.
6. **Engineer the product**: the final system is designed and built with proper quality.

Two types:
- **Throwaway prototyping**: the prototype is used only to understand requirements and is then discarded; the real system is built properly (often with waterfall).
- **Evolutionary prototyping**: the prototype is refined step by step until it becomes the final system.

#### Circumstances in which a prototype is beneficial
1. **Requirements are unclear or incomplete.** The customer defines general objectives but cannot state detailed inputs, processing or outputs. Seeing a prototype helps users discover what they really want.
2. **User interface is important.** For interactive systems (web portals, mobile apps, ATMs), the look and flow are best decided by letting users try screens rather than reading text.
3. **New or innovative systems** where neither user nor developer has prior experience, so a model is needed to explore the problem.
4. **Developer is unsure about technical issues**, such as the efficiency of an algorithm, the response time of a database, compatibility with an operating system or a new technology. A prototype tests feasibility before full commitment.
5. **High risk of building the wrong system**, where the cost of a misunderstanding is large; a prototype reduces this risk early.
6. **Users can be closely involved** and are available to evaluate versions and give quick feedback.
7. **Demonstrating feasibility or selling an idea** to management or a client before funding the full project.
8. **Requirements validation**: a prototype shows errors and omissions in the proposed requirements, and can also be used for early user training and as a basis for test cases.

Example: a hospital wants an online appointment system but staff cannot explain how booking, cancellation and doctor schedules should look. A quick clickable prototype of the booking screens is built in a week. Doctors and receptionists try it, ask for changes (show free slots by department, add SMS reminder), and after two or three rounds the requirements are clear enough to build the real system.

When **not** to use it: when requirements are already well known and stable, for very large systems where a prototype is too costly, or when users cannot spend time evaluating it. There is also a danger that customers treat a weak prototype as the finished product, or that developers keep poor quick-fix code in the final system.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. What is a prototype?
   A. The final polished product
   B. An early, working but incomplete version built quickly and cheaply to explore concepts and requirements
   C. A written specification document
   D. A test plan
   Answer: B. A prototype is a quick, incomplete working version used to demonstrate ideas and learn requirements. (Key point: Definition of prototype)

2. What does the quick design step of prototyping focus on?
   A. Database internals and efficiency
   B. Security hardening
   C. Visible aspects such as user interface and input/output formats
   D. Final deployment
   Answer: C. Quick design concentrates on what the user sees; efficiency and full error handling are ignored. (Key point: Quick design focus)

3. In which circumstance is prototyping most beneficial?
   A. Requirements are fully known and stable
   B. The system is huge and a prototype would cost too much
   C. Users cannot spare time for evaluation
   D. Requirements are unclear and the user interface is important
   Answer: D. Prototyping helps when users cannot state detailed requirements and need to try screens. (Key point: When prototyping helps)

4. Why would a developer build a prototype for technical uncertainty?
   A. To test feasibility, e.g. algorithm efficiency or database response time, before full commitment
   B. To avoid testing later
   C. To replace the requirements document
   D. To impress end users only
   Answer: A. A prototype tests technical issues early before the project is fully committed. (Key point: Technical feasibility)

## Related in other subjects

- [Model time scale, prototype day and moon](https://www.bctengineer.com/question.md?key=semester_3%2Ffluid_mechanics%3Amodel-time-scale-moon-gravity) — Fluid Mechanics, chapter 10
- [Steady 2D model: seepage under a dam](https://www.bctengineer.com/question.md?key=semester_8%2Fcomputational_techniques_in_civil_engineering%3Aseepage-under-dam-2d-model) — Computational Techniques in Civil Engineering, chapter 7, asked 3×
- [NDT circumstances; ultrasonic pulse velocity test](https://www.bctengineer.com/question.md?key=semester_5%2Fconcrete_technology_and_masonry_structure%3Andt-circumstances-upv) — Concrete Technology and Masonry Structure, chapter 5
- [Model testing and specific speed of turbine](https://www.bctengineer.com/question.md?key=semester_5%2Ffluid_machines%3Aturbine-model-similarity-numerical) — Fluid Machines, chapter 3