Encuetas dirigidas a los Consumidores de Tilapia

causations, and contrast between different stakeholders and, if possible, relate them to already existing functional and non-functional requirements.220 _{Figure 6 illustrates the}

novice mode.

Figure 6: VBRE novice mode Source: based on Thew & Sutcliffe (2018)

2.8 Prototype design: creating a solution based on stakeholder

requirements

At the end of the theory chapter, the author of this thesis presents a few options that practitioners have in order to design prototypes based on the requirements elicited using concepts and methods from the previous chapters. In order to visualize and communicate ideas to a group of stakeholders, a prototype is a suitable tool.221 _{There are multiple}

variations of how a prototype can be developed with different levels of advancement. A mutual characteristic that all of these variations share is the ability to produce feedback.222

219_{See Thew & Sutcliffe (2018)} 220_{See Thew & Sutcliffe (2018)} 221_{See Berger (2011)}

According to Hull et al. (2017), prototyping has three essential issues: 1) the prototype is providing too much detail, causing too much time spent developing it, 2) the prototype is pushed towards implementation too early, 3) the prototype is too impressive and

stakeholders want to use it operationally.223 _{When properly managing stakeholder}

requirements, the first two issues should not occur. The third issue can be countered through assuring the imaginary nature of a prototype, for example, by focusing on individual use cases instead of a complete product.224 _{The following chapter provides an}

overview of existing prototype categories. The concept of a use case and its importance for prototyping is explained in the subsequent chapter.

2.8.1 Prototype categories range from simple to complex solutions

Literature defines a variety of prototype categories that can be used to visualize ideas and concepts for stakeholders to receive feedback. Berger (2011) points out that the wording "prototype" can be misleading as it does not have to be technical in order to produce feedback. The following categories are listed by complexity, beginning with the most accessible category.

A Conceptual Model is the most basic form of prototype, as it tries to describe the ideas of the users in a conceptual workflow without the need to be technically feasible or realistic (Berger, 2011). Creators of such prototypes often need to explain their approach as it not visualized in any way.225

The Low-Fi Prototype already introduced a basic workflow that tries to include operational processes.226 _{However, functionality and technical feasibility are still not provided.}227

Users and designers are involved in creating this prototype.228 _{Typically, this category}

already offers paper-based visualization, which helps users with understanding the prototype better.229

223_{See Hull et al. (2017)} 224_{See Hull et al. (2017)} 225_{See Berger (2011)} 226_{See Berger (2011)} 227_{See Berger (2011)} 228_{See Berger (2011)} 229_{See Berger (2011)}

The next category, Mock-Up, is exclusively created by the designer and often advances the prototype to a digital medium.230 _{The Mock-Up should be visually unappealing to avoid}

the problem of users committing too early.231 _{While functionality is still absent, the}

workflow closely resembles the actual operational processes.232

A Dummy, also Click Dummy, represents the next iteration of prototypes. It is still created by the designer and lacks technical feasibility.233 _{However, the Click Dummy offers a}

refined visual design and represents the operational workflow accurately.234 _{In order to}

visualize the prototype digitally, practitioners often use browser-based solutions that can be used on any system or device.235

Next, the High-Fi Prototype incorporates software developers and designers into the prototype design process. As a result, the digital High-Fi Prototype distinguishes itself from the Click Dummy through the ability to provide most of the proposed functionality across operational workflows.236 _{Additionally, the way of how the prototype is used}

resembles the modality of the final product.237

The software developers exclusively generate the Alpha Grade Version that includes most of the proposed functions but lacks a refined visual design.238 _{The goal of this prototype is}

to demonstrate and test the basic functions that should be included in the final product.239

The most advanced prototype category, Beta Version, provides a polished solution, including functionality, feasibility, and visual design that works in the same way as the final product.240 _{Additionally, the workflow is fully operational.}241 _{In practice, Beta}

Versions are used to test prototypes for bugs and other issues and help solving them.242

230_{See Berger (2011)} 231_{See Berger (2011)} 232_{See Berger (2011)} 233_{See Berger (2011)} 234_{See Berger (2011)} 235_{See Berger (2011)} 236_{See Berger (2011)} 237_{See Berger (2011)} 238_{See Berger (2011)} 239_{See Berger (2011)} 240_{See Berger (2011)} 241_{See Berger (2011)} 242_{See Berger (2011)}

2.8.2 Use case development is best conducted via natural language

In order to translate the requirement specification from the VBRE process to viable prototypes, use cases are formulated. A use case is defined as "a goal-oriented set of interactions between external actors and the system under consideration."243 _Researchers

claim that the most suitable way of representing the behavior of a use case is to include natural language.244 _{They argue that natural language allows all kinds of stakeholders to}

understand the use case.245 _{However, there is no alignment on a specific textual description}

for a use case, resulting in the emergence of various templates and meta-models.246 _Textual

refinement of a use case can be achieved using the use case template that is described in table 4.247

243 _{Malan & Bredemeyer (2001), p. 1}

244_{See Siqueira (2018)} 245_{See Siqueira (2018)} 246_{See Siqueira (2018)}