Prototype and Prototyping

Some students have confusing about prototype, prototyping, and the purpose of prototyping in a SE process.  On this page, I show a few examples and explain them to those interested in.
(a) What is a prototype?
(b) What is prototyping?
(c) How does a software engineering process use prototyping?

  • The requirement R specifies that we need a bank account that allows cash deposit and withdrawal.
  • Q is a C++/Java program that implements an Account class that has two methods namely deposit(n) and withdraw(n), where n is the amount of cash.
  • P is a C++/Java program that implements an Account class in part. For instance, it has only implement deposit(n), and has a method withdraw(n) that has no method body (i.e., no code inside withdraw(n)).  Users can find that P is what they want (i.e., R), and request to full in the code in the method body of withdraw(n).
  • P1 is a C++/Java program that implements an Account class in part. Unlike P, it has two methods, namely deposit(n) and balance(), in which there is no code in deposit(n). Users may tell the developers that they do not need the balance() method.
  • P2 is a C++/Java program that implements an Account class in part. Unlike P, it has one method, namely deposit(n), in which all pieces of necessary code has been implemented. Users may tell the developers that deposit(n) is what they want, but they further request to implement a method known as withdraw(n).
  • R is the requirement. Q is an implementation of R. P, P1, and P2 are prototypes.

Explanatory Notes:

  • For Question (a): A prototype is an implementation. However, this implementation does not have all the required functions. Suppose that there is a requirement R, and its full implementation Q, and its prototype P. Ideally, for an input x, we would like P(x) to output what R(x) has specified. However, P has not been fully implemented R, and so there are some inputs (say y) such that P informs the caller that it cannot compute the output P(y). Whereas, since Q is a full implementation, Q(x) does output what R(y) has specified.  Note that, in the above scenario, P always outputs correctly for those inputs that P supports. That is, P is not a buggy program.


  • For Question (b): However, sometimes, both users and developers do not know R precisely. (We can imagine that R is unknown.) In this case, developers are hard to implement Q such that every of Q’s outputs is what R has specified. In this case, we implement a prototype P1 based on some understanding on the undocumented requirement R1, and then use P1 as it is. Since there is no specification (e.g., use case specification or analysis model), we say that we use a prototyping approach to developing a program (which is P1 in the scenario).


  • For Question (c): In a software engineering process, there are various phases. If prototyping is used in the requirement elicitation/capture, then we can verify whether P1 has implemented the needs of the users (which is R).  Ideally, the users tell the developers the difference between R and P1. Perhaps, users have an implementation P in their mind; and thus, they can tell us the difference between P and P1.  Based on the collected difference, we follow a software engineering process to revise the document or produce a new prototype P2. We may iterate this procedure until our latest prototype captures the requirement R.


Selected Tags

Tag Groups


ACM SigSoft
IEEE Software Engineering Online