Don’t drive away in your prototypes (46)

When thinking about prototypes most people will probably think about product (hardware) related prototypes. Full size cars at international shows or a representation of a park or a part of a city (scale model). In the foundation syllabus IREB mentions prototypes can be used multiple times during the requirements engineering process. Starting at the elicitation phase and at a later moment in time during the validation phase.

Disadvantage of the above mentioned hardware prototypes is that they can be very expensive (both time and money) to produce. If you are in the business of creating both hard- and software this will be a disadvantage. However if your product (or the biggest part of your product) is software, creating prototypes doesn’t have to take very long and also can be pretty cheap. The simplest prototype for a user interface can be just a sketch on a piece of paper (very fast, very cheap). Also referred to as a low fidelity prototype. Biggest benefit of any type of prototype is that it will help the stakeholders to envision what they (hopefully) will get in the end. During the elicitation phase it can help stakeholders to have a starting point for the requirements: far more easy to react on something then to have to start with a blank sheet of paper. Downside can be stakeholders are already ‘forced’ into a certain direction. They are already happy with the prototype and don’t challenge themselves to come up with something new. A prototype can also help to come up with additional requirements based on what they experience by interacting with the prototype.

Another challenge can be found in the interacting. There will not be that much interacting going on with a paper sketch of a user interface. Sure stakeholders can look at it. You can have multiple sketches, talk stakeholders through a sequence of sketches representing a sequence of interfaces. It still will only be looking, no touching. Stakeholders probably will prefer to have something that they can actually ‘use’. This is referred to as a high fidelity prototype There are multiple ways to create an interactive prototype. You could use tools. But you can also start building the software. And there you have the biggest concern to prototypes. Once you start building the prototype using actual software instead of tools, there is a legit possibility that stakeholders are that happy with the end result, they will ask you to just take it into production. We all know the prototype was never build for that purpose. It’s hacked together, not taking into account things like performance, interoperability or maintainability. Unfortunately I’ve come across multiple occasions where this has happened. Giving the maintenance department headaches for years to come trying to keep the software operational and maintained at full scale.

A prototype used during elicitation is used to tease and trigger the stakeholders in the journey towards getting the set of requirements as complete as possible. Lots to improve on a prototype like that. Most probably the same prototype will not be used during validation. A prototype used during validation should hold all requirements gathered until that moment in time. Stakeholders must be able to recognize and validate the requirements while interacting with the prototype. The prototype will be more matured compared with the prototype used during elicitation. Getting very close to the actual end product. Increasing the risk of actually taking the prototype into production as is.

Prototype are very useful within the process of requirements engineering. Just be very careful when building it in actual software. One advantage of hardware prototype: full size car prototypes don’t do vroom vroom, so nobody will ever drive it on a scale bridge!

This article is an article in the series about the versatile profession of requirements engineering. Every week a colleague of Improve Quality Services will share with the reader an aspect of requirements engineers from daily experience. Every article begins with a picture of a bridge. The bridge visualizes connecting two sides. In requirements engineering connecting different stakeholders assisting the stakeholders in collaboration and communication about requirements.

Articles published till date (articles 1 till 28 in Dutch):

1. Requirements (Piet de Roo, December 1, 2020)

2. Shared Understanding (Kaspar van Dam, December 8, 2020)

3. Context en requirements structuur (Patrick Duisters, December 15, 2020)

4. Van Twin Peaks naar Twin Pines (Patrick Duisters, December 22, 2020)

5. Modellen om te bouwen (Erwin Pasmans, January 5, 2021)

6. Minimaal Modelleren (Piet de Roo, January 12 2021)

7. Begrip en Vertrouwen (Benjamin Timmermans, January 19, 2021)

8. En wat als de specialisten het niet met elkaar eens zijn? (Benjamin Timmermans, January 26, 2021)

9. Waar zijn we nou helemaal mee bezig?! (Erwin Pasmans, February 2, 2021)

10. Soft skills? Keiharde wetenschap! (Kaspar van Dam, February 9, 2021)

11. … en nu enkele feiten: Requirement Attributen (Patrick Duisters, February 16, 2021)

12. Waarom, waarom, waarom, ... (Piet de Roo, February 23, 2021)

13. Een leven lang zorgen (Erwin Pasmans, March 2, 2021)

14. Casus: Requirements management bij een distributiecentrum in aanbouw (Eduard Hartog, March 11, 2021)

15. Iteratief versus Incrementeel (Kaspar van Dam, March 16, 2021)

16. Requirements of-the-shelf: geen maatwerk, geen requirements? (Erwin Pasmans, March 23, 2021)

17. Creatief door constraints (Piet de Roo, March 30, 2021)

18. 3 Amigo’s (Patrick Duisters, April 13, 2021)

19. 4 Amigos (of meer?) (Patrick Duisters, April 20, 2021)

20. Requirements, de CoronaCheck-app en Fred Flintstone (Benjamin Timmermans, April 28, 2021)

21. Meer kapiteins op 1 schip (of staan de beste stuurlui aan wal)? (Erwin Pasmans, May 4, 2021)

22. Hoe SMART is SMART? (Benjamin Timmermans, May 11, 2021)

23. Jip en Janneke (Piet de Roo, May 18, 2021)

24. Laten we het simpel houden (Patrick Duisters, May 25, 2021)

25. Dilemma's (Erwin Pasmans, June 1, 2021)

26. Living Documentation Event 2021 (Kaspar van Dam, June 8, 2021)

27. Non-functional Requirements (Patrick Duisters, June 15, 2021)

28. The Big Shift (Kaspar van Dam, June 22, 2021)

29. Why do we have these problems over and over again? (Erwin Pasmans, June 29, 2021)

30. Non-functionals, who cares? (Benjamin Timmermans, July 6, 2021)

31. Usability and UX, a revelation I had (Benjamin Timmermans, July 13, 2021)

32. How? (Piet de Roo, July 20, 2021)

33. Requirements and design? (Erwin Pasmans, July 27, 2021)

34. Tom's people skills to deal with the customers (Piet de Roo, August 3, 2021)

35. Requirements creep: the ideal pocketknife with 3000 functions (Benjamin Timmermans, August 10, 2021)

36. Requirements creep: good or bad? (Benjamin Timmermans, August 17, 2021)

37. End with the begin in mind (Piet de Roo, August 24, 2021)

38. Requirements: Do we really need them? (Kaspar van Dam, August 31, 2021)

39. Begin with the End in Mind (Patrick Duisters, September 7, 2021)

40. Solving the right problem (Piet de Roo, September 14, 2021)

41. Adapt requirements (and your process) to your development approach! (Erwin Pasmans, September 21, 2021)

42. ISTQB and IREB are joining forces (Piet de Roo, September 28, 2021)

43. New stakeholders (Benjamin Timmermans, October 5, 2021)

44. Just start over again (Erwin Pasmans, October 12, 2021)

45. Booking a desk at the office (Piet de Roo, October 19, 2021)