Storyboarding as a Means of Requirements Elicitation and User Interface Design: An Application to the Drones’ Industry

The goal of this chapter is to present the best practices and usage of storyboarding during the initial definition of multidisciplinary projects where partners from different backgrounds (engineering, arts, creative industries, etc.) collaborate to define the main user tasks to be implemented during the project. One of the challenges in this phase of the project is to be able to effectively communicate the ideas between the partners. Every background has his own concepts, technical language and procedures, and sometimes it is hard to convey in words the real meaning of an idea. It is even possible that different disciplines use the same tools, but have different names and different purposes. Storyboards are universally understandable and provide a common ground for sharing ideas and for discussing and discovering new points of view.


Introduction
Creative Industries (CIs) have used storyboarding for many years. It is a very useful and powerful tool for describing the content of a linear production, such as an animation film (Finch 2011). Storyboarding is a good collaborative technique, where all the members of the group can internalise the whole project and see the whole picture as well as small details. It also enables anyone to contribute his or her ideas effectively. Homogeneous teams of animators or audiovisual professionals regularly use this tool. Also, multidisciplinary multimedia production teams can work concurrently (Taylor 2013).
It is very common nowadays in the software development industry to design interactive systems based on user-centred design (UCD) processes. Any mid-tolarge-sized modern software project typically involves multidisciplinary teams composed of technical and not technical stakeholders: end-users, clients, producers, designers and engineers. The different and complementary perspectives of the team members define the requirements of the system to be constructed. The ISO standard 24765:2010(E) defines requirement as "a condition or capability that must be met or possessed by a system, system component, product, or service to satisfy an agreement, standard, specification, or other formally imposed documents" (ISO/IEEE 24765-2010(E)). The software requirements specification document is the result of the requirement analysis stage of the project, and must consider all aspects of the application, ranging from user needs to non-functional requirements, such as safety, security, performance, reliability or latency requirements.
The methodology to obtain clear user requirements is key for the success of the project. This methodology has to: 1. Get all team members involved in the early stages of the system design. 2. Allow for the effective communication of the design ideas among all members. 3. Document the decisions in a way that all team members can understand and use them in an appropriate way in later stages of the process.
Understanding user requirements is an integral part of information systems design and it is critical to the success of interactive systems. However, specifying these requirements is not so simple to achieve. As specified in the ISO 13407 standard, UCD begins with a thorough understanding of the needs and requirements of the users. The benefits can include increased productivity, enhanced quality of work, reductions in support and training costs, and improved user satisfaction (Maguire and Bevan 2002). Requirements analysis is not a simple process. There are many methodologies for user requirement analysis that can be used to achieve these goals: stakeholder analysis, context of use analysis, video recording, focus groups, interviewing, scenarios and use cases, storyboards, etc. (Maguire and Bevan 2002).
Storyboards are a key and efficient means to communicate results of user needs analysis to the team members of a multidisciplinary group of professionals involved in user-centred software engineering (UCSE) projects (Haesen et al. 2009). Storyboards contain sketched information of users, activities, devices and the context of a future application.
An additional challenge when collaborating within a multidisciplinary UCD team is communication within the team without information loss. One missing link in most user-centred processes is an approach and accompanying tool to progress from informal design artefacts (e.g. scenarios) towards more structured and formal design strategies (e.g. task models, abstract user interface designs) without losing any information. Existing tools and techniques often require specific knowledge about specialised notations or models, and thus exclude team members not familiar with these notations or models. Furthermore, functional information may be missing in informal design products, while structured design results may not always contain all non-functional information. Storyboards are a comprehensible notation that allows these shortcomings to be overcome (Haesen et al. 2016). Storyboarding has also proved to be a good methodology for developing interactive multimedia applications such as video games (Lambert and Jacobsen 2015).
A storyboard graphically represents a sequence of actions or events that the user and the system being designed go through to achieve a task. A scenario is one textual story about how a product may be used to achieve the task. It is therefore possible to generate a storyboard from a scenario by breaking the scenario into a series of steps which focus on interaction and creating one scene in the storyboard for each step (Rogers et al. 2011). The purpose for doing this is twofold: 1. To produce a storyboard that can be used to get feedback from users and colleagues. 2. To prompt the design team to consider the scenario and the product's use in more detail.
After this process is finished, the technical team can process the stories and develop a draft that is focused on the way the user will interact with a hypothetical application. This application implements the interactions portrayed in the storyboards. After the technical team validates this draft, the rest of stakeholders can evaluate it. Stakeholders can provide feedback with new suggestions, objections or confirmations. The technical team process this feedback and produce a prototype of the application that will have all the main features of the definitive application, taking into account the suggestions of the stakeholders. A number of cycles of design-test-implement are performed in order to refine the visual aspect of the application, workflows, ergonomics, etc. before developing the final system.

Using Design Thinking in AiRT
The main goal of the AiRT project is to provide the European creative industries with a new tool that will enable them to offer new services and to grow in the international market. To achieve this objective, we have designed the first RPAS that is specially designed for professional indoor use (Santamarina-Campos et al. 2018).
Inclusive and participatory methodologies and work tools have been used in order to achieve the specific results and objectives of the project. These methodologies have allowed collaboration and communication both internally (between the consortium) and externally (with the end-users) of the project. For this reason, Design Thinking methodology (Both 2009) has been used to ensure that: 1. Results are aligned with the values of the creative industries (García and Dacko 2015) from the initial stages of innovation processes. 2. Communication between the interdisciplinary team that makes up the consortium (composed of engineers, economists, artists, creatives, etc.) is effective.
This methodology (see Fig. 1) is centred on the user experience, focusing on the design process rather than the final product. It allows the convergence of different fields combined through "radical collaboration", with the common goal of implementing tools that enable new flows of thought based on intuition, critical thinking and creativity (Brown 2009).
Thereby, storyboarding can be found in the intersection between narrative, visual thinking, and design thinking (Beckman and Barry 2007; Wikström and Berglund 2011).

Methodology Development at AiRT
Design Thinking (Both 2009) has allowed the consortium to be connected to the experience of the creative industries. Creative Industries professionals have participated in the identification of needs and have interacted with the prototype during demonstrations. The aim was to learn from user feedback. Design Thinking is a Fig. 1 Methodologies used in the design of the Ground Control System (GCS) software. Source: Own elaboration, adapted from Both (2009) suitable methodology for this interdisciplinary consortium, formed by engineers, managers and creatives, and from the integration of experts from 13 sectors of the European creative industry (Santamarina-Campos et al. 2018). The five steps are analysed and developed below.
1st Phase. Empathise The project began with the analysis of the needs of the creative industries. This analysis was carried out with end-users, which allowed us to obtain consistent results. The technique of the Stakeholder Map was used to identify the potential users of the product. It allowed us to have a clear image of the users who had to intervene and participate in the analysis. Based on the stakeholder map defined by the consortium, the key informants who participated in the definition of the features of the system were identified through three focus groups in Spain, Belgium and the United Kingdom. The dynamics were prepared by means of a previous Documentary Investigation around the requirements related to aerial filming and photography, the use of drones and the security and data protection problems derived from them.
The key informants chosen at this stage came from 13 different sectors of the creative industries and they participated in the entire project process.
2nd Phase. Synthesise An analysis of the needs of the CIs and ethical and risk issues was carried out based on the information extracted in the previous phase. Qualitative Content Analysis, Social Network Analysis (SNA), and manual coding and categorisation of qualitative data were the methods used for processing the gathered information. The first step was to identify the real needs of the end-users. These needs drove us to define possible key solutions that provided added value and let us obtain an innovative result. The results obtained at this stage were the basis of the idea of the AiRT system.

3rd Phase. Ideation
The target of the ideation stage is that both CIs and creative professionals, who are part of the consortium, can define the functionalities to be implemented in the AiRT system. The AiRT system is composed of an RPAS that is driven automatically from land by a Ground Control System (GCS) software. The GCS runs on a standard tablet. Written scripts (Fig. 2) were elaborated, starting from the identification of the needs carried out in the initial phase, together with the specifications included in Annex 1 (part A) of the DoA, 1 in the Grant Agreement no. 732433.
These written scripts were subsequently transferred to graphic scripts (Storyboards) (Fig. 3) that represented the use of the AiRT system in different creative scenarios. Storyboarding was one of the main techniques used during the process of requirements elicitation. It allowed great visual and plastic content. Storyboarding eases creative and analytical thinking while facilitating communication between internal groups of the consortium. Innovative and feasible solutions arise around Fig. 2 Examples of written scripts that describe a hypothetical storyboard scenario. Source: Own elaboration storyboards. The use of this tool has allowed us to fulfil one of the main premises of the creative process of Design Thinking, "Show, don't tell" (Plattner 2010). This means that it is important to communicate the vision in an impacting and meaningful way by creating experiences, using illustrative visuals and telling good stories.
The use of this tool favoured expansive thinking. Programmers could communicate the main ideas that were drawn from the previous phase directly and more clearly, without value prejudices. The purpose of the use of storyboards was to help the creatives involved in the consortium to transfer real scenarios to the design process of the AiRT system. These scenarios created possible indoor spaces that would reflect the identified needs in different creative spaces.
An heuristic analysis of the main programmes for flight plans based on mesh or mosaic was performed in this phase. This analysis was also done for the best mapping and photogrammetry programmes available on the market. The goal of this study was to analyse existing solutions similar to our product in order to have a more complete perspective of issues around the usability and final design of our tool.
To conclude this phase, a storytelling of the history of the project was elaborated, with the target of informing the creative industries and other sectors of the potential of the tool.
4th Phase. Prototype In this phase, the ideas expressed in the previous stage were materialised. Bear in mind that the development of prototypes is not simply a way to validate ideas, but it is an integral part of the innovation process (Plattner 2010). Therefore, this phase carries out many other implicit goals. The AiRT RPAS is a complex system that involves a high-end Indoor Positioning System (IPS) technology that was in beta stage of development. AiRT RPAS can be seen as a real-world test bench for the IPS. A new drone was also developed in order to match the requirements of an indoor drone with support for professional cameras. This drone had its own standard Flight Control System (FCS). Finally, the Ground Control System (GCS) connects wirelessly to an On-board Control System (OCS). During this phase, all components of the system, FCS, OCS, GCS and IPS were integrated. Meanwhile, a software prototype that implemented the functionalities of the AiRT system was developed. This software runs on the GCS. It has to communicate bidirectionally with the server process running on the OCS. The design of this software was based on prioritised requirements, with the goal of making the solutions visible. The Human-Computer Interface of the software (user interface) was based on the heuristic analysis of the information extracted from the storyboards done in the previous stage.
Potential improvements were identified, but they were relegated for later developments, after users had a chance to interact with the product and provide feedback.
5th Phase. Tests During this stage, end-users in the three participating countries tested prototypes from a selection of scenarios relevant to the creative industries. The objective of this stage was to involve users in the identification of failures or in the contribution of new improvements, through the Participatory Action Research tool (PAR) (Chevalier and Buckles 2013). PAR focuses on the effort to integrate three main aspects: Participation of all the stakeholders, Action as an engagement with experience and history and Research to extract the knowledge (Fig. 4). The purpose of this type of technique is to obtain relevant data from key informants that allow subsequent interpretation and analysis of the facts from the experiences (Santamarina-Campos In parallel, the dynamics were recorded with the objective of using the "covert observation technique" (Bryman 2016), through the analysis of the filming of the sessions, and then interpretation was done using qualitative data analysis software.
A workshop is also another activity for making the tool known to the CIs among other sectors. The aim is to bring AiRT closer to the market. Finally, two storytelling lines will be developed: 1. One will show the whole process of the project, from the ideation phase to test. 2. Another one for commercial purposes only.

Requirements Elicitation and User Interface Design in AiRT
Requirements analysis is a set of activities performed to determine the needs or features that a new product should have. It is an important stage in any software engineering project. Requirements analysis is critical to the success of a software project. It helps to identify business needs or opportunities. It defines the functionality of a programme to a level of detail that is high enough to perform a system design. The requirements should be documented. Every requirement has to be: Recording. This phase is in charge of documenting the requirements including a summary, natural-language documents, storyboards and anything else that can affect any other area of the software production: data models, communication models, process specifications, etc. The software requirements specification document is the distillation product that emanates from all the requirements analysis process.
The first activity, eliciting was performed by using focus groups as seen in the 1st phase, Empathise. The second activity, Analysis, was made by using storyboards, as seen in the third phase of Ideation. The third activity, Recording, tried to detect in a first step the main areas where the requirements could be assigned. We used collaborative technologies for the development team. This allowed us to perform asynchronous collaboration, effective comments exchange, the integration and unification of definitions and the reduction of redundancy.
Although the goal of this phase was to obtain a list of user interface (UI) requirements, during the analysis many other requirements not related directly to UI appeared. These involved programming and communications requirements that emanated from the analysis of the user interface and software functionality analysis. The latter types of requirements are especially important for this project since they involve all the three development teams: software, IPS and drone development. These requirements are for internal use only and they were reserved for later use by the development team.
The storyboard scenarios, as described above, are descriptions of practical situations where professionals use the drone for recording needs. Most user requirements are obtained from storyboards. Several storyboards were proposed and catalogued.
Requirements have to be traceable. This means that every requirement has to be connected to the storyboard where it emerged, allowing for the quick location of both requirements and storyboards. We provided a unique identifier for each requirement and for each storyboard. References to storyboards follow the syntax: SourceType is the type of document where the storyboard is described. For instance, UC as an acronym for User Case, but there are other types of documents used during the analysis stage. XX is the number of the storyboard. page is the page number where the requirement appears inside of the storyboard.
After analysing the storyboards, the requirements are compiled on a list. This list may change during the development phase due to user feedback or the discovery of new emerging functionality that can complement or clarify some ambiguous requirements. After some time, and with the whole consortium's agreement, the requirements list is frozen. This list defines the initial functionality of the system. The goal of this step is avoiding requirements creep, that is, uncontrolled growth in the project's scope during the development phase.
As the requirements were identified, they were also classified. Related requirements were grouped into categories. Table 1 shows the categories used in the project.
Each category represents a state of the application workflow, or an area of the system.
A requirement can be assigned to: -A single category. For instance, a requirement such as "the initial calibration of the positioning system must be performed automatically" has been assigned to the category CALI. -Several categories. For instance, a requirement such as "the drone must not collide with any wall when performing the environment 3D mapping" may be assigned both to categories RECO and SAFE. Whenever a requirement is classified in more than one category, one of them is chosen as the primary.
The description of each requirement is organised in several fields (see Fig. 5): -Identifier (ID). It provides an identity (name) to the requirement. It follows the convention of RXXX where R is the short for "requirement" and XXX is the number assigned to this current requirement. Requirement IDs are never reused. Therefore, when two different requirements are found to overlap, one of the two IDs is deleted and never used again, and its requirement is assigned to the remaining IDs. Therefore, the final list of requirements will have gaps in the requirements IDs. This process helps with the requirement traceability. In flight FLY Applies whenever the drone is flying (for any purpose).
Source: own elaboration -Category. The category assigned to the requirement. It follows the code provided above. -Description. An explanation of the goal of the requirement. This list contains high-level requirements that, during development, may be subdivided into requirements that are more detailed. -Storyboards. This field enables us to relate each requirement with the storyboard it derived from, and therefore to trace it. There must be at least one customer need that justifies any function implemented in the system. There are many internal technical requirements that were not explicitly mentioned by the customers

Description
The application has to know or ask for the predefined operational limits of the drone (maximum speed, maximum acceleration, etc.), the gimbal and the RCAM The application has a file or a configuration which can be used to load these values. The same file or configuration should be loaded into the server on the OCS. The user can specify the minimum safety distance to obstacles. These values should be taken into account to perform the flight at "Mapping" step or at "Recording" step.

Actors
Client application, OCS, FCS Source Storyboards UC00:9 Precondition Define settings values is the first step before the drone takes off.

Comments
The values introduced by the user have to be in a valid interval. The safety distance to obstacles (walls) is needed to calculate the different heights at which the mapping could be done. These requirements have to be sent to the OCS in order to warn FCS to change trajectory in case security is compromised.
Responsible UPV Version 1.0 Fig. 5 Examples of requirement definition. Source: own elaboration because of the customer's lack of technical knowledge. These requirements have to also be traceable and have to appear in the list, although they are secondary requirements made by the development team. In any case, there is always a reference to the code assigned to the storyboard that justifies the current requirement. -Responsible. It is the team or the person in charge of developing this requirement.
They have to supervise or execute the correct implementation of the requirement. -Comments. They allow expanding or refining a bit more the description of the requirement. This field is not mandatory. -Version. It indicates the assigned version of the software when the requirement will be implemented. Current version of the software is V1.0. If the requirement is assigned to the first version of the drone, the requirement is mandatory. It has to be developed within the project scope. If the requirement is not important or it is not clear if industry will demand it urgently, it is set to a later version. If there is time enough to complete it, perhaps it will be developed and integrated in the current version. If the requirement demands a lot of work and it is not clear that the development could complete the requirement in time, it will be assigned to V2.0 for the future development of the drone.

Conclusions
Requirements Analysis is a complex process that involves users and developers during most of the software development cycle. At the beginning of the project, requirements are obtained using different techniques with all the stakeholders. Later, during development, requirements are refined and adapted to the development evolution, and it is necessary to keep users updated and take their feedback into account. We obtained and analysed the real needs of our users through three focus groups. We found that current indoor drones do not provide the features that creative industries demand, and thus we were able to detect many possibilities for the AiRT system. At this point, the use of storyboards made it possible to simplify and add a narrative and an appropriate context that eased the design process.
Storyboards provided visuals for the consortium's developers with real uses and potential user experiences, based on the identification of needs. Storyboards were an invaluable tool for developing the requirement list that describes the specific functionalities to be implemented in the AiRT system, and specifically in the GCS software. The graphic scripts helped to promote communication between software developers and the consortium's creatives.
Many GUI requirements were specific for this system since there is no comparable product on the market. CI users expressed their requirements from previous experiences with drones in outdoor scenarios. They also expressed: their problems in moving auxiliary equipment for filming indoors, especially in inhabited spaces or places with heritage value (Informant 6 and 8); invasive aspects involved in the use of auxiliary means such as lifting platforms, travel or sliders (Informant 1); the time-dependent condition of filming or photographing indoors with natural light and the difficulty of repeating identical shots (Informant 19); the limitations of auxiliary means of obtaining special footage (Informant 20); and experiences of using indoor drones, highlighting the need to incorporate an indoor positioning system and safety measures (Informant 13).
On the other hand, although current technology for outdoor drones is mature, this technology does not match the more demanding indoor requirements. Therefore, we had to push this technology to its end in order to reach the minimum specifications considered essential for the CI.
After the analysis of the user requirements, there were some additional technical requirements that arose because of the demands of future users. These requirements were mainly about: how the device is introduced in the industry's workflow; security specifications, some mandatory, some complementary; error control when flying; and other difficulties that appeared when implementing in restricted hardware platforms, for instance, the amount of geometry information that can be stored by the OCS depending on the memory available, transfer speed depending on the Wi-Fi network, rendering limits of the tablets used for the project, etc.
Putting the specifications together, we found that some were not feasible in the current state of drone technology. Others were also not feasible because they go beyond the project objectives and thus cannot be implemented with the given timeline and resources. So, some requirements have been postponed for later versions.
These specifications may still change, especially as beta versions of the system start to be used by the final users. Then they will realise the potential of the indoor drones and start to suggest more changes concerning the GUI.