DELIVERABLE D.3.4 SavingFood Platform Prototype Evaluation The methodology to be followed for the technical evaluation is the “Product Quality Model” from ISO/IEC 25010:2011. A

DELIVERABLE

D.3.4 SavingFood Platform Prototype Evaluation

2

Disclaimer

Any dissemination of results reflects only the author's view and the European Commission is not responsible for any use that may be made of the information it contains.

Copyright message

© Partners of the SavingFood2.0 Consortium, 2016 This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both. Reproduction is authorised provided the source is acknowledged.

3

Document Information

Grant Agreement Number: 688221 Acronym: SavingFood2.0

Full Title An innovative solution to tackle food waste through the collaborative power of ICT networks

Horizon 2020 Call ICT-10-2015, Collective Awareness Platforms for Sustainability and Social Innovation

Type of Action Research and Innovation Action

Start Date 1st January 2016 Duration: 24 months

Project URL www.savingfood.eu

Project Coordinator Vilabs

Deliverable D.3.4 SavingFood platform prototype evaluation

Work Package WP3

Date of Delivery Contractual M10 Actual

Nature R - Report

Dissemination Level P - Public

Lead Partner VILABS Lead Author: Fotis Moumtzis

Contributor(s) All partners

Reviewer(s): Apostolos Vontas (VILABS)

http://www.savingfood.eu/

4

Glossary Terms, abbreviations and definitions

Glossary Terms Definition

Test Case A set of tests that are conducted in each interface in order to specify all of the user possible choices in each page of the platform

Use Case A description of a general interaction between a user and a system in which the user achieves the goal he wants

Use Case Scenario A description of a typical sequence of steps and activities that a user hopes to achieve using a system or technology

User Story A goal that an identified user has in using a system

5

Table of Contents 1 Executive Summary .................................................................................................................................... 8 2 Introduction ................................................................................................................................................ 9

2.1 Structure of this Document .............................................................................................................. 10 3 Technical Evaluation Methodology........................................................................................................... 11

3.1 The Product Quality Model Methodology ........................................................................................ 11 3.2 SavingFood Platform: Product Quality Evaluation ............................................................................ 14

4 Use Cases actors and Main Use Cases ...................................................................................................... 17 4.1 User roles .......................................................................................................................................... 17 4.2 Main Use Cases ................................................................................................................................. 18

5 Wireframe Testing .................................................................................................................................... 20 6 Use Case Scenario Summary in Wireframe Implementation .................................................................... 64

6.1 Use Cases for shared Activities ......................................................................................................... 65 6.1.1 Use Case Scenario: 1 – Registration ............................................................................................ 65 6.1.2 Use Case Scenario: 2 – Log On .................................................................................................... 66 6.1.3 Use Case Scenario: 3 - Modify donation Details ......................................................................... 67 6.1.4 Use Case Scenario: 4 - Log off ..................................................................................................... 68

6.2 Use Cases for Co-ordinator only ....................................................................................................... 69 6.2.1 Use Case Scenario 5 - View donation .......................................................................................... 69 6.2.2 Use Case Scenario: 6 - Schedule Event ....................................................................................... 70 6.2.3 Use Case Scenario: 7 - Register donation ................................................................................... 71 6.2.4 Use Case Scenario: 8 - Accept Recipient ..................................................................................... 72 6.2.5 Use Case Scenario: 9 - Send notification ..................................................................................... 73

6.3 Use Cases related to Volunteers ....................................................................................................... 74 6.3.1 Use Case Scenario: 10 – Share (Event) feedback ........................................................................ 74 6.3.2 Use Case Scenario: 11 - View event ............................................................................................ 75

6.4 Uses Cases related to Donor (only)................................................................................................... 76 6.4.1 Use Case Scenario: 12 - Set donation needs ............................................................................... 76

6.5 Use Cases related to Travel Intermediary only ................................................................................. 77

6.6 Use cases related to Travel Intermediary and to Recipient .............................................................. 77 6.7 Use Cases related to Recipient only.................................................................................................. 77

6.7.1 Use Case Scenario: 13- Accept Donation .................................................................................... 77 7 Conclusions ............................................................................................................................................... 78

6

8 Annex ........................................................................................................................................................ 79 8.1 Use Cases not Implemented ............................................................................................................. 79

8.1.1 Use Cases for shared Activities not implemented ...................................................................... 79 8.1.1.1 Use Case Scenario: 1 - View History/ rewards.................................................................... 79

8.1.1.2 Use Case Scenario: 2 - Generate Schedule......................................................................... 79 8.1.2 Use Cases for Co-ordinator only not implemented .................................................................... 80

8.1.2.1 Use Case Scenario: 3 - Set preferences .............................................................................. 80 8.1.2.2 Use Case Scenario: 4 - Review / Run report ....................................................................... 80 8.1.2.3 Use Case Scenario: 5 - Generate Event report ................................................................... 81 8.1.2.4 Use Case Scenario: 6 - Confirm Date/Time ........................................................................ 81 8.1.2.5 Use Case Scenario: 7 - Close Event..................................................................................... 82 8.1.2.6 Use Case Scenario: 8 - Advertise/ Publicize event.............................................................. 82 8.1.2.7 Use Case Scenario: 9 - Accept Event .................................................................................. 83 8.1.2.8 Use Case Scenario: 10- Notify Recipient ........................................................................... 83 8.1.2.9 Use Case Scenario: 11- View Status ................................................................................... 84

8.1.3 Use Cases related to Volunteers not implemented .................................................................... 84

8.1.3.1 Use Case Scenario: 12 - Register travel needs ................................................................... 84 8.1.3.2 Use Case Scenario: 13 - Confirm Attendance ..................................................................... 85 8.1.3.3 Use Case Scenario: 14 - Schedule travel ............................................................................ 85 8.1.3.4 Use Case Scenario: 15 - Offer travel ................................................................................... 86

8.1.4 Uses Cases related to Donor (only) not implemented ................................................................ 86 8.1.4.1 Use Case Scenario: 16 - Rate recipient ............................................................................... 86

8.1.5 Use Cases related to Travel Intermediary only, not implemented ............................................. 87 8.1.5.1 Use Case Scenario: 17 - Schedule transport....................................................................... 87 8.1.5.2 Use Case Scenario: 18 - Confirm arrangements ................................................................. 87

8.1.6 Use cases related to Travel Intermediary and to Recipient not implemented ........................... 88 8.1.6.1 Use Case Scenario: 19 - Arrange transport ........................................................................ 88

8.1.7 Use Cases related to Recipient only not implemented ............................................................... 88 8.1.7.1 Use Case Scenario: 20 - Register donation needs .............................................................. 88

8.1.7.2 Use Case Scenario: 21- Confirm receipt ............................................................................. 89 8.1.7.3 Use Case Scenario: 22 - Rate donor ................................................................................... 89

7

Table of Tables Table 1: The Sub-characteristics and their relevance to the Saving Food Platform ......................................... 14 Table 2: Key Performance Indicators ................................................................................................................ 16 Table 3: Summary of the main User roles associated with Scenarios .............................................................. 18

Table of Figures Figure 1: A product quality model view based on the ISO/IEC 25010:2011 standards .................................... 11 Figure 2: Use Cases in Saving Food Platform .................................................................................................... 18 Figure 3: Wireframe 1 of 30 – Home Page ........................................................................................................ 20 Figure 4: Wireframe 2 of 30 - Login Form ......................................................................................................... 21 Figure 5: Wireframe 3 of 30 – 2nd step in Registration ..................................................................................... 22 Figure 6: Wireframe 4 of 30 - 1st Step in Registration ...................................................................................... 23 Figure 7: Wireframe 5 of 30 – Dashboard Interface ......................................................................................... 24 Figure 8: Wireframe 6 of 30 – Third Step In Registration.................................................................................. 26 Figure 9: Wireframe 7 of 30 – Food Donations ................................................................................................. 27 Figure 10: Wireframe 8 of 30 – Events Calendar .............................................................................................. 28 Figure 11: Wireframe 9 of 30 –Settings (profile).............................................................................................. 30 Figure 12: Wireframe 10 of 30 – Donation from organization .......................................................................... 32 Figure 13: Wireframe 11 of 30 – Successful registration interface ................................................................... 34 Figure 14: Wireframe 12 of 30 – New Donation ............................................................................................... 35 Figure 15: Wireframe 13 of 30 – Food Donations table ................................................................................... 36 Figure 16: Wireframe 14 of 30 – Farmers Market ............................................................................................ 37 Figure 17: Wireframe 15 of 30 – New Event Creation ...................................................................................... 39 Figure 18: Wireframe 16 of 30 – Events Calendar ............................................................................................ 40 Figure 19: Wireframe 17 of 30 - Settings .......................................................................................................... 42 Figure 20: Wireframe 18 of 30 – Settings: Users .............................................................................................. 44 Figure 21: Wireframe 19 of 30 – Settings- Donations ....................................................................................... 46 Figure 22: Wireframe 20 of 30 - Donation details............................................................................................. 47 Figure 23: Wireframe 21 of 30 –Create New Donation .................................................................................... 48 Figure 24: Wireframe 22 of 30 - Event Feedback ............................................................................................. 50 Figure 25: Wireframe 23 of 30 – Invitations Import/ CSV Import / Manual Add .............................................. 51 Figure 26: Wireframe 24 of 30 – User Management ....................................................................................... 53 Figure 27: Wireframe 25 of 30 – Users account enabling interface ................................................................. 54 Figure 28: Wireframe 26 of 30 – Bridge Manager ............................................................................................ 55 Figure 29: Wireframe 27 of 30 - Register Donation .......................................................................................... 57 Figure 30: Wireframe 28 of 30 – Invitations Import ......................................................................................... 59 Figure 31 Wireframe 29 of 30 – Donation Feedback ....................................................................................... 60 Figure 32: Wireframe 30 of 30 - Invitations ...................................................................................................... 62

8

1 Executive Summary

The present document is the deliverable “D.3.4 SavingFood 2.0 platform prototype evaluation” and will provide a formal evaluation of the prototype and outline criteria and methodology to be used for the evaluation. The main objective in this document is to evaluate the progress made in the current status of the prototype and to give guidance towards further development of the platform according to the specifications set out in the previous deliverables.

The methodology to be followed for the technical evaluation is the “Product Quality Model” from ISO/IEC 25010:2011. A set of characteristics are presented and defined, as well as the internal and external measures of software quality are described. Since the functionalities are only outlined in the Wireframes a software evaluation cannot take place at this stage. However, the presentation of the method and its adjustment to the particular characteristics of the SavingFood Platform aims to provide a preliminary draft that will function as a standard for the full technical analysis that will take place at later cycles of the project.

The primary task in this document is to showcase and evaluate the deployed functionalities through a number of test cases and respective screenshots accompanying each step of the supported service. To achieve that, we examined the degree of accomplishment of the Use Cases as set in the D3.1 Platform architecture, while testing the Wireframes. Furthermore, me examine which Use Case is accomplished in each Wireframe and try to highlight some logic errors, as well as some questions that we think that emerge in each Wireframe.

The secondary task is to examine whether the Use Cases are conducted. As a Use Case is essentially a sequence of user choices in his interaction with the platform, our approach was to define the sequence of wireframes that constitute a Use Case. In this task we classify the Use Cases first by their status (whether they are implemented or not) and second by the User Role that carries them out.

Finally, we make some conclusions based on the tasks completed, where we point out the progress and the issues that we consider to arise on the basis of the evaluation

9

2 Introduction

The present document reports on the technical work carried out towards the development of the Saving Food platform during the project’s lifetime and on the development of each component and their integration in the interim system. Additionally, it describes the implementation decisions that have been made towards the development of the provisional interface.

The main goals of the project’s technical deliverables as defined in Annex 1(part A) “Research and Innovation action” are intended to contribute towards the development of a preliminary technical solution. The major goals are:

1. Seek and manage specific feedback on the platform through engagement with WP4 and the use case users and associated communities via appropriate channels.

2. Early demonstrations of interim versions of the platform determine any further requirements and feed these into the design/build process iteratively (Task 3.1 and 3.2).

3. A minimum of three feedback cycles, that will be planned to be as responsive to end user feedback as possible and facilitate adoption and sustainability beyond the end of the project lifecycle.

The task “D3.4 -System Evaluation” is part of the WP3 Work package. The WP3’s main object is to design and implement the customized platform to satisfy requirements from the stakeholders identified in WP2. In the document AnnexI_DoA_688221_SavingFood2.0 is explicitly stated that the design and implementation of the platform includes interfaces to external sources for querying and integration at runtime, and user support for different stakeholder types and their roles and requirements. All this contributes to the work package’s main goal, which is to outline the platform’s main features that will form the basis for the trial implementations in WP4. The fact that this document is part of WP3 and therefore must fulfill its role to form the basis for the trial implementations, combined with the fact that it is essentially the first in a set of documents that are part of the technical evaluation, leading us to the fundamental question below: How can this document pragmatically contribute towards the effective implementation of the platform? The answer is that this document, in addition to the general description of the systems goals and its methodology, must provide a report of the technical evaluation that will function as a template for future evaluations and monitoring of the project’s progress. Therefore, along with the evaluation attempt a secondary task is performed. This task aims to describe possible features of the first pilot implementation that might be later useful.

This document will be then used as the technical baseline to initiate development activities.

10

2.1 Structure of this Document In this document:

x In chapter 3 is presented the methodology which will be used for the technical evaluation of the platform in this document and also in forthcoming deliverables of the same technical content. We will use the “Product Quality Model" from the ISO / IEC 25010: 2011

o In chapter 3.1 the product quality model is presented, that describes the internal and external measures of the wireframe quality.

o In chapter 3.2 the Product Quality Evaluation Framework, is presented. x In chapter 4 are presented the Actors and Main Use Cases Use Cases according to which the

evaluation will take place x In chapter 5 we will test the wireframes. The wireframes will be tested through a series of Test

Cases. Each Test Case for every wireframe will be matched to a relevant Use Case, as they were determined in the Deliverable D3.1 Platform architecture.

x In chapter 6 there are listed the Use Cases defined in D3.2 SavingFood platform prototype that have been implemented and they are matched with the corresponding wireframes and their possible test cases.

x In chapter 7 there are outlined the conclusions for the tests performed in chapters 4 and 5. x Finally, an Annex at the end of the document which includes the templates for the evaluation of the

use cases not implemented yet. These templates will be used in the next version of this deliverable.

11

3 Technical Evaluation Methodology For the technical evaluation of the Saving Food platform, the “Product Quality Model” from ISO/IEC 25010:2011 will be used. In paragraph 4.1 the framework is presented and is discussed in the prism of the project, whether the categories are relative to the project or not, while in 4.2 the specific, project-related KPIs are described, where the analysis will be based. This section describes the technical analysis, which will take place at later cycles of the project.

3.1 The Product Quality Model Methodology The product quality model describes the internal and external measures of software quality. Internal measures describe a set of static internal attributes that can be measured. The external measures focus more on software as a black box and describe external attributes that can be measured.

Figure 1: A product quality model view based on the ISO/IEC 25010:2011 standards

In general, this model evaluates software quality using a structured set of characteristics (each of

them including other sub-characteristics), which are the following:

1. Functional suitability - The degree to which the product provides functions that meet stated

and implied needs when the product is used under specified conditions.

2. Performance efficiency The performance relative to the amount of resources used under stated conditions.

3. Compatibility - The degree to which two or more systems or components can exchange information

and/or perform their required functions while sharing the same hardware or software environment.

Functional Suitability

Functional completenes

s

Functional Correctness

Functional Appropriate

ness

Performance Effieciency

Time Behaviour

Resource Utilization

Capacity

Compatibility

Co-existence

Interoperability

Operability

Appropriateness recognizability

Technical Learnability

Ease of use

User error protection

User interface aesthetics

Technical Accessibility

Reliability

Maturity

Availability

Fault tolerance

Recoverability

Security

Confidenciality

Integrity

Non-repudiation

Accountability

Authenticity

Maintainability

Modularity

Reusability

Analysability

Modifiability

Testability

Portability

Adaptability

Installability

Replaceability

12

4. Operability - The degree to which the product has attributes that enable it to be understood,

learned, used and attractive to the user, when used under specified conditions.

5. Reliability - The degree to which a system or component performs specified functions under

specified conditions for a specified period of time.

6. Security - The degree of protection of information and data so that unauthorised persons or

systems cannot read or modify them and authorised persons or systems are not denied access

to them.

7. Maintainability - The degree of effectiveness and efficiency with which the product can be

modified.

8. Portability - The degree to which a system or component can be effectively and efficiently transferred from one hardware, software or other operational or usage environment to another.

The following table showcases the sub-characteristics of each category and indicates their relativity to the Saving Food platform.

Sub-characteristics Definition

Related to Saving Food

Yes/ No/ Debatable

Functional suitability

Functional completeness Degree to which the set of functions covers all the specified

tasks and user objectives. Yes

Functional correctness System provides the correct results with the needed degree

of precision. Debatable

Functional appropriateness

The functions facilitate the accomplishment of specified

tasks and objectives. No

Performance efficiency

Time behaviour Response, processing times and throughput rates of a system, when performing its functions, meet requirements.

No

Resource utilisation The amounts and types of resources used by a system,

when performing its functions, meet requirements. Debatable

Capacity The maximum limits of a product or system parameter

meet requirements. No

Sub-characteristics Definition Related to Saving Food

13

Compatibility

Co-existence Product can perform its functions efficiently while sharing environment and resources with other products.

No

Interoperability A system can exchange information with other systems and use the information that has been exchanged.

No

Operability

Appropriateness recognisability

Users can recognise whether a system is appropriate for their needs, even before it is implemented. No

Technical Learnability The system has functions, which enable learning specified operations of it.

Debatable

Ease of Use System has attributes that make it easy to operate and control.

Debatable

User error protection System protects users against making errors. Yes


User interface enables pleasing and satisfying interaction for the user.

Debatable

Technical Accessibility System can be used by people with the widest range of characteristics and capabilities.

Yes

Reliability

Maturity System meets needs for reliability under normal operation. Debatable

Availability System is operational and accessible when required for use. Yes

Fault tolerance System operates as intended despite the presence of hardware or software faults

No

Recoverability System can recover data affected and re-establish the desired state of the system is case of an interruption or a failure.

Debatable

Sub-characteristics Definition Related to Saving Food

Security

Confidentiality System ensures that data are accessible only to those authorized to have access Yes

14

Integrity System prevents unauthorized access to, or modification of, computer programs or data.

Yes

Non-repudiation Actions or events can be proven to have taken place, so that the events or actions cannot be repudiated later.

Debatable

Accountability Actions of an entity can be traced uniquely to the entity. No

Authenticity The identity of a subject or resource can be proved to be the one claimed.

No

Maintainability

Modularity System is composed of components such that a change to one component has minimal impact on other components.

No

Reusability An asset can be used in more than one system, or in building other assets

No

Analysability Effectiveness and efficiency with which it is possible to assess the impact of an intended change.

No

Modifiability System can be effectively and efficiently modified without introducing defects or degrading existing product quality.

No

Testability Effectiveness and efficiency with which test criteria can be established for a system

Yes

Portability

Adaptability System can effectively and efficiently be adapted for different or evolving hardware, software or usage environments. Debatable

Installability Effectiveness and efficiency with which a system can be successfully installed and/or uninstalled.

No

Replaceability Product can be replaced by another specified software product for the same purpose in the same environment.

No

Table 1: The Sub-characteristics and their relevance to the Saving Food Platform

To validate that the platform fulfils adequately the qualifying technical requirements, a set of technical methodologies will be used.

3.2 SavingFood Platform: Product Quality Evaluation Based on the tables presented in the previous sections that reveal which criteria should be measured during the SavingFood operation, and based on the fact that the ISO/IEC 25010:2011 standard does not define specific attributes (measuring ways) for each one of the sub-characteristics, the following list of indicators have been devised in order to allow the technical assessment of the SavingFood platform. It needs to be noted that due to the nature of the project and based on the operation conditions of the pilots, some of the

15

below mentioned indicators are considered optional, as their measurement might not produce meaningful results or at least their results are not apparent at this stage. Some of the indicators of the quality model that are not applicable are commented as non-applicable.

Sub-characteristics KPI Calculation Type Mandatory/ Optional

Functional completeness

Percentage of completed Use Cases / Usage Scenarios

(Completed Use Cases / Defined Use Cases) * 100 %

Mandatory

Functional correctness

Percentage of Use Cases without reported bugs, after tests

(Completed Use Cases without bugs / Defined Use Cases) * 100 %

Optional

Ease of Use

Number of clicks required to reach requested information

Number of clicks required to reach required information

Non-applicable

Number of clicks required to initiate event

Number of clicks required to initiate event

Optional

User error protection

System crash on user errors Does the whole system crash on user errors? YES/NO

Mandatory

Error message availability Is there a comprehensive information message on errors? YES/NO

Optional


User Interface Accessibility standardisation

No. of User Interface Accessibility standards followed

Optional

Technical Accessibility

Cross-Browser Accessibility SavingFood platform accessible and operational through different browsers

Mandatory

Cross-Device Accessibility SavingFood platform accessible and operational through different devices (e.g. PC / Laptop/ Tablet / Smartphones

Mandatory

Mobile friendliness Pass Google mobile Test. YES/NO Optional

Colour Blindness Are colours compliant? YES/NO Non-applicable

Maturity

Max. Concurrent Users Supported

No. of Max. Concurrent Users Recorded

Optional

Simultaneous Requests

No. of Simultaneous Requests (e.g. page open)

Optional

Confidentiality Incidents of accessing prohibited information

No. of incidents recorded Mandatory

Integrity Incidents of authentication mechanism breaches

No. of incidents recorded Mandatory

Authenticity Level of User Authenticity Can you identify whether a subject is the one it claims to be? YES/NO/Partially

Mandatory

16

Level of Data Resource Authenticity

Can you identify whether a resource is the one it claims to be?

Mandatory

Modifiability % of Update Effectiveness

(No. of updates preformed without noticing operational problems)/(No. of updates performed)

Optional

Testability Level of Testing Are tests able to probe the SavingFood platform behaviour? YES/NO/Partially

Mandatory

Table 2: Key Performance Indicators

17

4 Use Cases actors and Main Use Cases 4.1 User roles

The following are the main actors within the surplus food management ecosystem, directly involved in making it work as they were defined in D3.1 Platform architecture:

ROLE SUB-ROLE DESCRIPTION

DONOR Those who are willing to make donation of food. They may be registered directly with the platform; or may be contacted by the Co-ordinator at the partner site on a regular or ad hoc basis

FARMER For Gleaning, Farmers represent the main Donor type. However, they would not normally register with the platform: the Co-ordinator at the partner site would act as intermediary and contact the farmer to request a donation etc.

RECIPIENT The organisation benefiting from the donations made. These are generally charities.

TRANSPORT

INTERMEDIARY Where the Recipient themselves is unable to collect a donation, there would be one or more Transport intermediaries who would arrange transport to collect the donations and deliver to the Recipient.

VOLUNTEER Anyone prepared to give time in support of the food donation co-ordination, gathering (gleaning), travel, etc.

INTERNAL Those Volunteers registered with the platform who might then autonomously view events and commit support

EXTERNAL Those Volunteers not registered with the platform but who are either known to the Co-ordinator(s) at the partner site or see events advertised on social media and who may wish to provide support

CO-ORDINATOR1

Usually at the partner site, the Co-ordinator takes responsibility for all or some part of the organisation of an event or other donation activity

GLEANING The Co-ordinator at the partner site organising a gleaning event

PARTNER SITE The Co-ordinator at the partner site who oversees all donation activities at and for the partner

FARMERS

MARKET An external body who acts as a communication link between the partner organisation and a given farmers market. They would not

1 There is a difference between the overall co-ordinator and regional co-ordinator. The difference is basically what they can and cannot access; so it would be difficult to test at the moment.

18

ROLE SUB-ROLE DESCRIPTION

usually be registered with the platform

VOLUNTEER The Volunteer at an event such as a Farmers Market who is responsible for the practical organisation and management of a given event / activity

ANONYMOUS USER Anyone not known to the platform (i.e., not registered) who views the external pages of the SavingFood portal

Table 3: Summary of the main User roles associated with Scenarios

These user roles form the basis for the Use case descriptions.

4.2 Main Use Cases The diagram in the following figure represents the external use cases as agreed with the pilot partners that were defined in Work package 2 drafted in D3.1 Platform architecture.

Figure 2: Use Cases in Saving Food Platform

19

This section contains details on each Use case. Figure 2 provides a summary of all the high-level Use cases along with the main actors. Those colored green represent shared activities; i.e., those used by more than a single actor. Those in blue identify the tasks which the Co-ordinators needs to carry out. In consequence, once implemented, they also highlight the benefit the SavingFood platform would deliver: these are the tasks which would be made significantly easier by the platform. In addition, those shown in pink relate to volunteering, while those in orange relate to donations.

For specific implementation, additional detail has been added and some Use case variants generated as the internal representation of what is to be implemented. Although some final detail needs to be fleshed out, a complete set of Use cases are presented in the next chapter.

20

5 Wireframe Testing In this section we will evaluate the functionalities of the wireframes that were designed and presented in the Deliverable D3.2 Platform prototype, and are available at the following URL, hosted on the Adobe Creative Cloud platform: SavingFood_Wireframes

Since the wireframes are considered a blueprint for the web-based portal, by evaluating these essentially we evaluate the preliminary draft of the portal. Each wireframe or set of wireframes will be matched to the Use Cases, as they were determined in the Deliverable D3.1 Platform architecture and referenced to each relevant Use Case Table of Section 6.

After this task is completed the Use Cases that have not been implemented in the current wireframe version will also be summed up in the Annex.

The following Wireframe (1 of 30) represents the homepage interface. The user options are highlighted with the circle pointers.

Figure 3: Wireframe 1 of 30 – Home Page

The Test Cases for the Wireframe are performed in the table below. There are listed the Users actions, the Wireframe to which every Test Case leads and the Use Case Scenario to which it belongs:

https://xd.adobe.com/view/0c14b000-d75b-4feb-5b5b-0b28073d0423/

21

Figure 3 - Wireframe 1 of 30 – Home Page

Button/ User’s Action Figure - Wireframe which results from the test case

Use Case Scenario

Test Case 1 User presses Sign in Figure 4: Wireframe 2 of 30 - Login Form Use Case Scenario: 2 – Log On

Test Case 2 User presses Sign Up Figure 5: Wireframe 3 of 30 – 2nd step in Registration Error: Wireframe 1 should result from this test case

Use Case Scenario: 1 - Registration

Test Case 3 User presses Get started

Figure 6: Wireframe 4 of 30 - 1st Step in Registration


The Next Wireframe (2 of 30) represents the Login Form. The user options are highlighted with the circle pointers.

Figure 4: Wireframe 2 of 30 - Login Form


22



Use Case Scenario /

Test Case 1 User Presses Saving Food Figure 3: Wireframe 1 of 30 – Home PageFigure 3: Wireframe 1 of 30 – Home Page

The User returns to the Homepage

Test Case 2 User presses Sign Up Figure 6: Wireframe 4 of 30 - 1st Step in Registration


Test Case 3 User presses Login Figure 7: Wireframe 5 of 30 – Dashboard Interface

Use Case Scenario: 2 – Log On

Test Case 4 User presses Register Figure 6: Wireframe 4 of 30 - 1st Step in Registration


The Next Wireframe (3 of 30) represents the second step in the registration process. The user options are highlighted with the circle pointers.

Figure 5: Wireframe 3 of 30 – 2nd step in Registration


23


Button/ User’s Action

Figure - Wireframe which results from the test case

Use Case Scenario (steps)

Test Case 1 User Presses Saving Food



Test Case 2 User presses Sign in



Test Case 3 User presses Sign Up



Test Case 4 User presses Continue

Figure 8: Wireframe 6 of 30 – Third Step In Registration





The Next Wireframe (4 of 30) represents the first step in the registration process. The user options are highlighted with the circle pointers.



24




Test Case 1 User Presses Saving Food Figure 3: Wireframe 1 of 30 – Home Page


Test Case 2 User presses Sign in Figure 4: Wireframe 2 of 30 - Login Form


Test Case 3 User presses Continue Figure 5: Wireframe 3 of 30 – 2nd step in Registration


The Next Wireframe (5 of 30) represents the Dashboard. The user options are highlighted with the circle pointers.

Figure 7: Wireframe 5 of 30 – Dashboard Interface


25





Test Case 1 User Presses Events

Figure 10: Wireframe 8 of 30 – Events Calendar

Preliminary step to access functionalities concerning Events

Test Case 2 User Presses Food Donations

Figure 9: Wireframe 7 of 30 – Food Donations

Preliminary step to access functionalities concerning Food Donations

Test Case 3 User Presses the Settings Button

Figure 11: Wireframe 9 of 30 –Settings

This test case results the wireframe 9 in which there are many data and options. The functionality resulting is the settings interface

Test Case 4 User Presses Log out


This test Case returns to the Home Page of SavingFood

Test Case 5 User Presses New Events


This test case results the events Calendar interface

Test Case 6 User Presses

Match

Figure 12: Wireframe 10 of 30 – Donation from organization

This test Case results an example of a Donation post from which the user can Match or edit a donation

Conclusions / Issues

The Dashboiard Interface

Possible need for implementation of a user-role specific dashboard.

26

The Next Wireframe (6 of 30) represents the 3d step in the registration. The user options are highlighted with the circle pointers.

Figure 8: Wireframe 6 of 30 – Third Step In Registration





Use Case Scenario


Figure 3: Wireframe 1 of 30 – Home Page The User returns to the Homepage

Test Case 2 User presses Submit

Figure 13: Wireframe 11 of 30 – Successful registration interface


27

The Next Wireframe (7 of 30) represents the main interface from which the Donor achieves the Use Case Scenario: 12 - Set donation needs. The user options are highlighted with the circle pointers.



Figure 8 – Wireframe 7 of 30 – Home Page




Test Case 1 User presses Saving Food

Figure 7: Wireframe 5 of 30 – Dashboard Interface – Error: Wireframe 1 should result from this test case


Test Case 2 User presses Events



Test Case 3 User Presses Settings Button

Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in which there are many data and options. The functionality resulting is

28

the settings interface


Figure 3: Wireframe 1 of 30 – Home Page This functionality returns the user to the homepage

Test Case 5 User Presses New Food Donation

Figure 14: Wireframe 12 of 30 – New Donation

1st step in Use Case Scenario: 12 - Set donation needs user: Donor

Test Case 6 User Presses Switch to Platform manager

Figure 15: Wireframe 13 of 30 – Food Donations table

Results the platform manager interface for managing Donors

The Next Wireframe (8 of 30) represents the Events Calendar. The user options are highlighted with the circle pointers.



29




Use Case Scenario


Figure 7: Wireframe 5 of 30 – Dashboard Interface – Malfunction: Wireframe 1 should result from this test case or the Button Saving Food should be altered


Test Case 2 User Presses Food Donations


Preliminary step to access functionalities concerning Food donations

Test Case 3 User Presses Settings Button

Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in which there are many data and options. The functionality resulting is the settings interface



Test Case 5 User Presses New Event

Figure 17: Wireframe 15 of 30 – New Event Creation

1st step in creating a new Event in Use Case Scenario: 6 - Schedule Event

Test Case 6 User selects an event from the existing events

Figure 16: Wireframe 14 of 30 – Farmers Market

The Coordinator views a created Event in Use Case Scenario: 6 - Schedule Event

Test Case 7 User Presses Map to view the Map and the Events & Home location


The Coordinator views a created Event in Use Case Scenario: 6 - Schedule Event

Test Case 8 The message Wireframes only: Switch to Volunteer view demonstrates the interface displayed to the volunteer


The interface for the view of the Volunteer over the events appears as in Wireframe 16


The Use Case Scenario “Schedule Event”

The Use Case Scenario “Schedule Event” as demonstrated in the Wireframes implements a set of Coordinator’s possible actions:

x The creation of a new event x The viewing of already created events in a list

30

x The viewing of a single, already created, event

It is not clear if the Coordinator is going to be able to mass-register the Events, if he can edit an already created event, and how the events-list are going to be displayed.

The next Wireframe (9 of 30) represents Settings Interface. The user options are highlighted with the circle pointers.

Figure 11: Wireframe 9 of 30 –Settings (profile)






Test Case 1 User presses SavingFood

Figure 7: Wireframe 5 of 30 – Dashboard Interface – Error: Wireframe 1 should result from this test case or the Button Saving Food should be altered





31

Test Case 3 User presses Food donations



Test Case 4 User presses Logout


This functionality returns the user to the homepage

Test Case 5 User presses Users

Figure 20: Wireframe 18 of 30 – Settings: Users

Is the first step in enabling a user. This is part of the Use Case Scenario: 8 - Accept Recipient

Test Case 6 User presses Platform

Figure 19: Wireframe 17 of 30 - Settings

The resulting Interface when Coordinator selects “Platform” is not part of a Use case Scenario. This could be a new Use case Scenario named e.g. “Register Platform Settings”

Test Case 7 User presses Donations

Figure 21: Wireframe 19 of 30 – Settings- Donations

Preliminary step to access functionalities concerning Food donations. The Use Case Scenarios concerning Donations are: Use Case Scenario: 7 - Register donation and Use Case Scenario: 5 - View donation


The Overall “Settings” Page.

It is a key interface resulting many wireframes associated with many Use cases. In subsequent versions of the platform this interface has a key role to the development of the platform

It includes Use Case Scenarios carried out by Co-ordinators and also by Users with different User Rights: For example the “Profile” Settings (The previous Wireframe) is meant only for Volunteers, Donors etc. The Platform Settings is destined to be used by platform CO-ordinators . This leads us to suggest: The role of the administrator would be useful so that a user with increased responsibilities is able to manage all system settings as well as the coordinators and the overall technical system.

32

The Next Wireframe (10 of 30) represents an interface that is related to Use Case Scenario: 3 - Modify donation Details . The user options are highlighted with the circle pointers.
















Test Case 4 User presses the Settings Button

Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in which there are many data and options. The functionality

33

resulting is the Settings interface



Test Case 6 User presses Edit

Figure 23: Wireframe 21 of 30 –Create New Donation

The Edit Button (which is expected to edit the current Donation) results a Wireframe that is related to Use Case Scenario: 3 - Modify donation Details

Test Case 7 User presses Match

Figure 22: Wireframe 20 of 30 - Donation details


User presses Edit The Edit Button selection (which is expected to edit the current Donation) results a Wireframe that is related to the Creation of a new donation. If the “registering” of the Donation and the creation of a new one have the same fields to be filled in, then in the Figure 22: Wireframe 20 of 30 - Donation details should instead of “New Donation” renamed “Edit Donation”

Overall data that constitute a donation

The data that constitute the donation have to be selected. Here those are:

x Transport: which are the alternatives. Is there going to be a drop down menu?

x Pick Up Window x Temperature Reqs: Is there going to be a drop down menu?

E.g. Cooling required/ Non temperature-sensitive / Deep Freezing necessary

x Packaging Pre-packed . Which are the alternatives: E.g. Bulk Cargo, Bags of X kg, Pallets, m3 , liters

x Contents. User enters text? Or is there going to be a list of products. This is important for matching

x Total is the measurement unit kg only?

Modify Donation details

The use case “Modify donation details” as determined in the Use Cases is assigned to both the Volunteer and the Reciepient. Are those using the same interface?

34

Figure 13: Wireframe 11 of 30 – Successful registration interface












Test Case 3 User presses Sign up



Test Case 4 User presses Edit your profile


Editing profile is not clearly matched to a Use Case Scenario. This action is likely a part of Use Case Scenario: 1 - Registration. The Edit profile selection is expected to lead to an interface where the user edits his profile. Instead it leads to a interface where more choices are possible

35

The Next Wireframe (12 of 30) represents the interface where the Donor carries out the Use Case Scenario: 12 - Set donation needs . The user options are highlighted with the circle pointers.














Figure 9: Wireframe 7 of 30 – Food Donations – Malfunction: Wireframe 13 should result from this test case or the Button Food Donations should be altered *


Test Case 4 User presses the Figure 11: Wireframe 9 of 30 –Settings This test case results

36

Settings Button the wireframe 9 in which there are many data and options. The functionality resulting is the Settings interface



Test Case 6 User presses the Select Bridge checkbox


There is no relevant Use Case

The Next Wireframe (13 of 30) represents an interface where the Co-ordinator manages the Food Donations The managing of Donations from the Coordinator has no relevant Use Case. The user options are highlighted with the circle pointers.



37




Test Case 1 User Presses Saving Food Figure 7: Wireframe 5 of 30 – Dashboard Interface – Malfunction: Wireframe 1 should result from this test case or the Button Saving Food should be altered


Test Case 2 User Presses Events Figure 10: Wireframe 8 of 30 – Events Calendar


Test Case 3 User Presses Match Figure 12: Wireframe 10 of 30 – Donation from organization

Use Case Scenario: 7 - Register donation

Test Case 4 The message Wireframes only: Switch to Food Donor view demonstrates the interface displayed to the Food Donor


Results the interface referring to Donations displayed to the Donor

The Next Wireframe (14 of 30) represents the 2nd step in Use Case Scenario: 6 - Schedule Event. The user options are highlighted with the circle pointers.


38






Test Case 1 User presses Saving Food







Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in which there are many data and options. The functionality resulting is the Settings interface

Test Case 4 User presses Log out



Test Case 5 User presses Give Feedback

Figure 24: Wireframe 22 of 30 - Event Feedback

Use Case Scenario: 10 - Share feedback

39

The Next Wireframe (15 of 30) represents the main interface for the creation of a new event. The user options are highlighted with the circle pointers.

Figure 17: Wireframe 15 of 30 – New Event Creation
















Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in

40

which there are many data and options. The functionality resulting is the Settings interface



Test Case 6 User Presses Submit


Is the second step in creating a new Event in Use Case Scenario: 6 - Schedule Event

The Next Wireframe (16 of 30) represents the main interface that realizes the Use Case Scenario: 11 - View event. The user options are highlighted with the circle pointers.



41









This test case results the wireframe 9 in which there are many data and options. The functionality resulting is the Settings interface

Test Case 3 User presses Logout Figure 3: Wireframe 1 of 30 – Home Page


Test Case 4 User selects an Event Figure 16: Wireframe 14 of 30 – Farmers Market

Use Case Scenario: 11 - View event

Test Case 5 The user selects the message Wireframes only: Switch to Platform Manager View


The view of the events as presented to the Co-ordinator appears

42

The Next Wireframe (17 of 30) represents the Platform Settings menu. The user options are highlighted with the circle pointers.

Figure 19: Wireframe 17 of 30 - Settings
















Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in

43

which there are many data and options. The functionality resulting is the Settings interface



Test Case 6 User presses Profile

Figure 11: Wireframe 9 of 30 –Settings Use Case Scenario: 1 - Registration



Registers the pending User’s approval and edits the already registered users




Test Case 9 User presses Invite List

Figure 25: Wireframe 23 of 30 – Invitations Import/ CSV Import / Manual Add

44

The Next Wireframe (18 of 30) represents the Users Settings interface. The user options are highlighted with the circle pointers.








Figure 7: Wireframe 5 of 30 – Dashboard Interface – Malfunction: Wireframe 1 should result from this test case or the Button Saving The User returns to the Homepage Food should be altered









Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in which there are many data and

45

options. The functionality resulting is the Settings interface




Figure 7: Wireframe 5 of 30 – Dashboard Interface



Figure 19: Wireframe 17 of 30 - Settings The resulting Interface when Coordinator selects “Platform” is not part of a Use case Scenario. This could be a new Use case Scenario named e.g. “Register Platform Settings”




Test Case 9 User presses Review

Figure 27: Wireframe 25 of 30 – Users account enabling interface

The Coordinator accepts or denies the registration to a new User.

Test Case 10 User presses Edit

Figure 26: Wireframe 24 of 30 – User The User Enables or disables an already registered User


test Case 9: (Review pending Approval)

The “Review” Pending approval and the interface to which it leads have no suiting Use Case Scenario. A Possible new Use case for this function could be “Manage/Register Users”

test Case 9: (Edit Users)

Who can edit user assigned with the role of CO-ordinator? Can a Co-Ordinator edit details referring to another Co-ordinator. Possible need for a new Role of Administrator.

Test Case 9&10 (Edit,Review)

Approving or disapproving the User’s registration is the same as enabling or disabling them?

46

he Next Wireframe (19 of 30) represents the Food Donation Settings interface. The user options are highlighted with the circle pointers.











Figure 11: Wireframe 9 of 30 –Settings Use Case Scenario: 1 - Registration


Figure 20: Wireframe 18 of 30 – Settings: Users Registers the pending User’s approval and edits the already registered users


Figure 19: Wireframe 17 of 30 - Settings The resulting Interface when Coordinator selects “Platform” is not part of a Use case Scenario. This could be a

47

new Use case Scenario named e.g. “Register Platform Settings”

Test Case 5 User presses Set up Bridge

Figure 28: Wireframe 26 of 30 – Bridge Manager


The Next Wireframe (20 of 30) represents main page in which the recipient accepts or rejects the Donation . The user options are highlighted with the circle pointers.

Figure 22: Wireframe 20 of 30 - Donation details









Test Case 2 User Presses Accept Donation

Figure 29: Wireframe 27 of 30 The Recipient accepts the Donation. This is an alternative step in Use Case Scenario: 13-

48

Accept Donation

Test Case 3 User Presses Reject Donation


The Recipient rejects the Donation. This is an alternative step in Use Case Scenario: 13- Accept Donation

The Next Wireframe (21 of 30) represents an interface realizing the Use Case Scenario: 12 - Set donation needs. The user options are highlighted with the circle pointers.








Figure 7: Wireframe 5 of 30 – Dashboard Interface – Malfunction: Wireframe 1 should result from this test case or the Button Saving The User returns to the Homepage Food should be altered


49











Test Case 6 User selects the “Let platform manager choose” checkbox


The Donor selects the Recipient preferences. This is an action related to Use Case Scenario: 12 - Set donation needs

50

The Next Wireframe (22 of 30) represents the Event Feedback interface. The user options are highlighted with the circle pointers.

Figure 24: Wireframe 22 of 30 - Event Feedback














This test case results the wireframe 9 in which there are many data and options. The functionality resulting

51

is the Settings interface






2nd step in Use Case Scenario: 10 - Share feedback

The Next Wireframe (23 of 30) represents an interface from which the Cooperator sends Invitations to Users. The user options are highlighted with the circle pointers










52











Test Case 6 User presses Review

Figure 30: Wireframe 28 of 30 – Invitations Import

1st step in Use Case Scenario: 9 - Send notification

53

The Next Wireframe (24 of 30) represents an interface where the Co-ordinator disables a registered user. The user options are highlighted with the circle pointers.

Figure 26: Wireframe 24 of 30 – User Management
















Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in which

54

there are many data and options. The functionality resulting is the Settings interface



Test Case 6 User presses Disable


The Co-ordinator disables a registered user

The Next Wireframe (25 of 30) represents an interface where the Co-ordinator disables a registered user. The user options are highlighted with the circle pointers.



55








Test Case 2 User presses Enable

Figure 26: Wireframe 24 of 30 – User The Co-ordinator enables a registered user


test Case 3: (Review pending Approval)

The “Enable” Pending approval and the interface to which it leads have no suiting Use Case Scenario. A Possible new Use case for this function could be “Manage/Register Users”

The Next Wireframe (26 of 30) represents an interface where The Cooperator registers the food donation. In particular by adding a bridge the Coordinator allows donors to automatically offoer their donation to the selected charity . The user options are highlighted with the circle pointers.

Figure 28: Wireframe 26 of 30 – Bridge Manager


56


















Test Case 6 User presses Add Bridge


The Cooperator registers the food donation. This is the 2nd step in Use Case Scenario: 7 - Register donation

Test Case 7 User presses Select


Is Part of the process of setting up a Bridge.


test Case 7 The Button “Select” seems to be part of this workflow: The Cooperator selects the Food Donor and the Charity and then the user can directly donor to the selected charity. This seems to be part of the Use Case Scenario: 6 - Schedule Event. An issue here is if the donor can only enter an event if he is approved by the Cooperator. This might be dysfunctional in case that there are many donors: Every Donor should then be assigned and this might be timewasting.

57

The Next Wireframe (27 of 30) represents the interface displayed when the Recipient accepts a donation. The user options are highlighted with the circle pointers.

Figure 29: Wireframe 27 of 30 - Register Donation










Figure 10: Wireframe 8 of 30 – Events Calendar Preliminary step to access functionalities concerning Events


Figure 9: Wireframe 7 of 30 – Food Donations – Malfunction: Wireframe 13 should result from this test case or the Button Food Donations should be altered *


Test Case 4 User presses Figure 11: Wireframe 9 of 30 –Settings This test case results the

58

the Settings Button

wireframe 9 in which there are many data and options. The functionality resulting is the Settings interface



Test Case 6 User presses Give Feedback

Figure 31 Wireframe 29 of 30 – Donation Feedback

The Recipient gives feedback on the donation.


test Case 6 (Give Feedback)

The recipient gives feedback about the donation. There is no corresponding Use Case Scenario. The Use Case Scenario that seems to be close to that action is the Error! Reference source not found. from the not implemented use cases . Although the resulting Wireframe when the user presses Give Feedback is Figure 31 Wireframe 29 of 30 – Donation Feedback which header is Donation Feedback. The donation Feedback is not one of the Use Case Scenarios determined in D3.1 Platform architecture. Is there need for a New Use case Scenario? E.g. Donation Feedback

59

The Next Wireframe (28 of 30) represents an interface form where the Coordinator sends Invitations. The user options are highlighted with the circle pointers.

Figure 30: Wireframe 28 of 30 – Invitations Import














Test Case 4 User presses Figure 11: Wireframe 9 of 30 –Settings This test case results

60

the Settings Button

the wireframe 9 in which there are many data and options. The functionality resulting is the Settings interface



Test Case 6 User presses Add


2nd step in Use Case Scenario: 9 - Send notification


Purpose of the Wireframe 28

Is sending an invitation related to Use Case Scenario: 9 - Send notification or is there need of new Use Case? Is “Send Notification” a functionality close to a newsletter?

The Next Wireframe (29 of 30) represents the Donation Feedback interface. The user options are highlighted with the circle pointers.

Figure 31 Wireframe 29 of 30 – Donation Feedback

61













Figure 9: Wireframe 7 of 30 – Food Donations – Error: Wireframe 13 should result from this test case or the Button Food Donations should be altered *







Figure 29: Wireframe 27 of 30 -


test Case 6 (Submit) The recipient gives feedback about the donation. There is no corresponding Use Case Scenario.

test Case 6 (Submit) Wireframes 27 and 29 are in a loop.

62

The Next Wireframe (30 of 30) represents the Invitation interface. The user options are highlighted with the circle pointers.

Figure 32: Wireframe 30 of 30 - Invitations












Figure 9: Wireframe 7 of 30 – Food Donations – Error: Wireframe 13 should result from this test case or the Button Food Donations should be altered *



Figure 11: Wireframe 9 of 30 –Settings This test case results the wireframe 9 in which there are many data and

63

options. The functionality resulting is the Settings interface



Test Case 6 User presses Import


3d step in Use Case Scenario: 9 - Send notification


Workflow Loop Wireframes 23, 28 and 30 are in a loop

64

6 Use Case Scenario Summary in Wireframe Implementation

In the current section we provide a series of Use Case Scenario testing that demonstrate the preliminary deployment of the platform facilitating also its testing and validation. The Use Case Scenario testing were selected according to the system’s envisioned functionality that is defined by the system’s use cases documented in the D3.1 Platform architecture. The Use Cases in this chapter are the use cases implemented in the Wireframes. The Use Cases that are not implemented in the Wireframes are shown in the Annex.

Saving Food Use Case Scenario Use Case ID =

Test

Scenario: A descriptive name for the Use case Users:

Which of the user role(s) would make use of the interaction represented by the Use case

Description A short description for the Use case Scenario and for the result the user achieves with its accomplishment

Scenario Sequence

The Steps required for the user to achieve his goals as selections in the Wireframes

Assumptions Any related / prerequisite Use case or other precondition necessary for the implementation of the scenario

Possible Modifications

Suggestions that we believe could improve the platform’s usability and utility

65

6.1 Use Cases for shared Activities

6.1.1 Use Case Scenario: 1 – Registration Saving Food Use Case Scenario Use Case 1

Test

Scenario: Registration Users:

Co-ordinator, Internal Volunteer, Donor, Travel Intermediary, Recipient

Description This test case aims to demonstrate how the user creates an account in the platform.

Scenario Sequence

Step1: The User presses Sign up and Get Started : Test Cases 2 & 3 in Figure 3: Wireframe 1 of 30 – Home Page

Step2: The User accepts the terms and conditions and presses “Continue”: Test Case 4 in Figure 5: Wireframe 3 of 30 – 2nd step in Registration

Step3: The user fills in data referring to his account (E-mail, Password, Confirm Password) and presses Continue: Test Case 4 in Figure 5: Wireframe 3 of 30 – 2nd step in Registration

Step4: The user fills in fields referring to personal or organizational data and presses Submit: Test Case 2 in Figure 8: Wireframe 6 of 30 – Third Step In Registration

Assumptions

x The system checks on email verification, on Password and Confirm Password matching, and on Password strength. A good practice is that the Password is a combination of letters numbers and special characters.

x In step 2 of the Use Case the user cannot click continue without having the checkbox checked as in Figure 6: Wireframe 4 of 30 - 1st Step in Registration

x The user may use only features of the portal that are allowed by his permission level, which is determined by his role.

Possible Modifications/ Issues

Modulation of requested fields according to the selection of a specific role. The data referring to additional profile information could vary depending on the selected role. For example the required fields could vary on a Person or an Organization.

Captcha field necessary in order to determine whether or not the user is human. This feature could enhance security level.

The user must select the role he wants to have in the platform: The roles are Co-ordinator, Volunteer, Donor, Travel intermediary and Recipient. The role could be selected from a drop down menu.

After the registration is finished, it is a good practice that the system asks the user to login.

There might be a confusion between who decides the roles, multiple roles, and switching between multiple roles.

66


6.1.2 Use Case Scenario: 2 – Log On

Saving Food Experimentation Scenario Use Case 2

Test

Scenario: Log Οn Users:


Description This test case aims to demonstrate how the user, who is registered with the platform, logs in

Scenario Sequence

Step1: Press “Sign in” in Figure 4: Wireframe 2 of 30 - Login Form

Step2: Accept the terms and conditions and press “Continue”

Assumptions -

Possible Modifications -


Use Case

67

6.1.3 Use Case Scenario: 3 - Modify donation Details

Saving Food Experimentation Scenario Use Case Scenario 3

Test

Scenario: Modify donation Details Users:

Co-ordinator,

Description The Coordinator modifies the donation Details

Scenario Sequence Partially Realized in Figure 14: Wireframe 12 of 30 – New Donation

Assumptions Fields for creating a new donation and modifying a donation are the same


-

Use Case Scenario: 3 - Modify donation Details

The Next Wireframe (11 of 30) represents the interface displayed to the user when he finishes his registration. The user options are highlighted with the circle pointers.

68

6.1.4 Use Case Scenario: 4 - Log off

Saving Food Experimentation Scenario Us Use Case Scenario 4

Test

Scenario: Log off Users:


Description The User logs off the platform

Scenario Sequence The user Selects the Logoff Button in the top right corner of the Wireframes

Assumptions -


Use Case Scenario: 4 - Log off

69

6.2 Use Cases for Co-ordinator only

6.2.1 Use Case Scenario 5 - View donation


Test

Scenario: View donation Users:

Co-ordinator

Description The User views the donation

Scenario Sequence Partially realized in Figure 15: Wireframe 13 of 30 – Food Donations table

Assumptions The User views a list of Donation but also the details for a particular Donation


Use Case Scenario: 5 - View donation

70

6.2.2 Use Case Scenario: 6 - Schedule Event


Test

Scenario: Schedule Event Users:

Co-ordinator

Description The Coordinator schedules an Event

Scenario Sequence

The Co-ordinator creates a new event following the next two steps

Step1: : The User presses “New Event” as in Figure 10: Wireframe 8 of 30 – Events Calendar

Step2: : The User presses “Submit” as in Figure 17: Wireframe 15 of 30 – New Event Creation

The Co-Ordinator views a created Event :

By selecting one of the events from the Event Calendar as in Figure 10: Wireframe 8 of 30 – Events Calendar and

By selecting an event from the map as in Figure 10: Wireframe 8 of 30 – Events Calendar

Assumptions

“Schedule Event” include the functionalities:

1. Creating a new Event 2. View already created Events in a list 3. View a single created Event

Possible Modifications It is not clear if the Coordinator is going to be able to mass-register the Events, if he can edit an already created event, how the events-list are going to be displayed and manage

Use Case Scenario: 6 - Schedule Event

71

6.2.3 Use Case Scenario: 7 - Register donation


Test

Scenario: Register donation Users:

Co-ordinator

Description The Coordinator registers the Donation

Scenario Sequence

1st step: The User selects the Set Up Bridge Button as in Figure 21: Wireframe 19 of 30 – Settings- Donations to create a connection …

2nd step: The User selects the button Select as in wireframe Figure 28: Wireframe 26 of 30 – Bridge Manager

Assumptions A donation is already made by the Donor


The actual requirements behind the “Set up bridge” selection need clarification


72

6.2.4 Use Case Scenario: 8 - Accept Recipient


Test

Scenario: Accept Recipient Users:

Co-ordinator

Description The Coordinator accepts the Recipient

Scenario Sequence

1st step : The Co-Ordinator selects the tab “Users” as in Figure 11: Wireframe 9 of 30 –Settings

2nd step : The Co-Ordinator selects “Review” or ”Edit” as in Figure 20: Wireframe 18 of 30 – Settings: Users

3d step : For the selection of Review in Wireframe 18 the Figure 27: Wireframe 25 of 30 – Users account enabling interface appears. In this wireframe the user selects “Enable”

4th step : For the selection “Edit” in Wireframe 18 the Figure 26: Wireframe 24 of 30 – User Management appears

Assumptions The Co-Ordinator can approve/deny the pending User’s approval or Edit already approved Users


In Figure 20: Wireframe 18 of 30 – Settings: Users the “Pending Approval” and “All Users” could be listed in different Pages.

The Users listed under Pending approval should have a different indication on the button selection which edits them, for example “Edit”. In the resulting wireframe (Figure 27: Wireframe 25 of 30 – Users account enabling interface) the choices should be “Accept Registration” and “Deny Registration” instead of “Enable” and “Edit”.

We would expect that there is an agreed “limit” to the number of entries on a list and we are assuming that any drop down or list view will be navigable via shortcuts.

Use Case Scenario: 8 - Accept Recipient

73

6.2.5 Use Case Scenario: 9 - Send notification


Test

Scenario: Send notification Users:

Co-ordinator

Description The Coordinator sends notification

Scenario Sequence

1st step: The Coordinator selects Review as in Figure 25: Wireframe 23 of 30 – Invitations Import/ CSV Import / Manual Add

2nd step: The User presses Add as in Figure 30: Wireframe 28 of 30 – Invitations Import

3d step: The User presses Import as in Figure 32: Wireframe 30 of 30 - Invitations

Assumptions -


Renaming the Button Next to Manual Add in Wireframe 23 and from Review to Add

Use Case Scenario: 9 - Send notification

74

6.3 Use Cases related to Volunteers

6.3.1 Use Case Scenario: 10 – Share (Event) feedback


Test

Scenario: Share feedback Users:

Internal Volunteer

Description The Volunteer offers Feedback

Scenario Sequence

1st step: The Volunteer selects “Give Feedback” as in Figure 16: Wireframe 14 of 30 – Farmers Market

2nd step: The Volunteer selects “Submit” as in Figure 24: Wireframe 22 of 30 - Event Feedback

Assumptions -


Use Case Scenario: 10 - Share feedback

75

6.3.2 Use Case Scenario: 11 - View event


Test

Scenario: View event Users:


Description The volunteer views an event

Scenario Sequence The Volunteer selects The Events displayed as in Figure 18: Wireframe 16 of 30 – Events Calendar

Assumptions -


-

Use Case Scenario: 11 - View event

76

6.4 Uses Cases related to Donor (only)

6.4.1 Use Case Scenario: 12 - Set donation needs


Test

Scenario: Set donation needs Users:


Description The recipient registers the types of food they are interested in, so they can be notified / match-made with donations

Scenario Sequence

1st step :The user selects New Food Donation as in Figure 9: Wireframe 7 of 30 – Food Donations

2nd step: The User fills in the donation details as in Figure 14: Wireframe 12 of 30 – New Donation

Assumptions -


-

Use Case Scenario: 12 - Set donation needs

77

6.5 Use Cases related to Travel Intermediary only No Use Case is implemented for this user in the Wireframes.

6.6 Use cases related to Travel Intermediary and to Recipient The Use Case Scenario for the two Users is the “Arrange Transport”. It is not implemented in the Wireframes

6.7 Use Cases related to Recipient only

6.7.1 Use Case Scenario: 13- Accept Donation


Test

Scenario: Accept donation Users:

Recipient

Description The Recipient accepts the Donation

Scenario Sequence The Use Case is partially realized in Figure 22: Wireframe 20 of 30 - Donation details

Assumptions -


Use Case Scenario: 13- Accept Donation

78

7 Conclusions

In this deliverable we propose the methodology that has to be used for the evaluation of the platform and the attempt that has been made to adjust this methodology to the needs of the project. During the evaluation, as we were able to test the Wireframes only, we essentially examined to which grade the Use Cases, as set in the deliverable D3.1 Platform architecture, have been implemented.

Our conclusion is that the basic, and most vital for the project development functionalities have been showcased. However, a significant number of Use Cases have not been implemented at all. Logical Gaps have been identified and there has been made an attempt to propose some adjustments that can contribute to the overall improvement of the platform.

With this deliverable we provide a report of the technical evaluation conducted so far. In addition, the overall methodology presented will function as a template for future evaluations and monitoring of the project’s total progress that will take place in the 14th month: D3.7 SavingFood 2.0 platform evaluation and will provide formal evaluations of the platform available at that period. In the next deliverable, an updated version of the methodology and the KPIs for evaluation, will be provided.

79

8 Annex 8.1 Use Cases not Implemented

8.1.1 Use Cases for shared Activities not implemented

8.1.1.1 Use Case Scenario: 1 - View History/ rewards

Saving Food Scenario Use Case 1

Test

Scenario: View History/ rewards Users:

Co-ordinator, Internal Volunteer, Donor, Recipient

Description The Users view history

Scenario Sequence There is no Wireframe implementation

Assumptions


8.1.1.2 Use Case Scenario: 2 - Generate Schedule

Saving Food Scenario Use Case Scenario 2

Test

Scenario: Generate Schedule Users:

Co-ordinator, Travel Intermediary

Description The Co-ordinator and the Travel Intermediary generate a travel schedule


Assumptions


80

8.1.2 Use Cases for Co-ordinator only not implemented

8.1.2.1 Use Case Scenario: 3 - Set preferences


Test

Scenario: Set preferences Users: Co-ordinator

Description The Coordinator sets the Event Preferences


Assumptions


8.1.2.2 Use Case Scenario: 4 - Review / Run report


Test

Scenario: Review / Run report Users: Co-ordinator

Description The Coordinator manages the report


Assumptions


81

8.1.2.3 Use Case Scenario: 5 - Generate Event report


Test

Scenario: Generate Event report Users: Co-ordinator

Description The coordinator creates an event report


Assumptions


8.1.2.4 Use Case Scenario: 6 - Confirm Date/Time


Test

Scenario: Confirm Date/Time Users: Co-ordinator

Description The Coordinator confirms Date and time for the Event


Assumptions


82

8.1.2.5 Use Case Scenario: 7 - Close Event


Test

Scenario: Close Event Users: Co-ordinator

Description The Coordinator closes an Event


Assumptions

Close Event means finalize the conducting of the Event .

This can an mean 2 things:

1. the Coordinator signals that the event is ‘full up’ (i.e., there are enough volunteers); or

2. the Coordinator completes / sees that all details have been provided for an event which has now taken place.


8.1.2.6 Use Case Scenario: 8 - Advertise/ Publicize event


Test

Scenario:

Advertise/ Publicize event

Users: Co-ordinator

Description Inform potential volunteers and also potential recipients of an event.

Scenario Sequence Is not implemented in the Wireframes

Assumptions


83

8.1.2.7 Use Case Scenario: 9 - Accept Event


Test

Scenario: Accept Event Users: Co-ordinator

Description The coordinator accepts an event


Assumptions These Events to be accepted are created by another User?


8.1.2.8 Use Case Scenario: 10- Notify Recipient


Test

Scenario: Notify Recipient Users: Co-ordinator

Description The coordinator notifies the recipient


Assumptions


84

8.1.2.9 Use Case Scenario: 11- View Status


Test

Scenario: View Status Users: Co-ordinator

Description The coordinator views the status of an Event


Assumptions


8.1.3 Use Cases related to Volunteers not implemented

8.1.3.1 Use Case Scenario: 12 - Register travel needs


Test

Scenario: Register travel needs Users: Internal Volunteer

Description The volunteers register the travel needs


Assumptions


85

8.1.3.2 Use Case Scenario: 13 - Confirm Attendance


Test

Scenario: Confirm Attendance Users: Internal Volunteer

Description The volunteers confirm their attendance


Assumptions


8.1.3.3 Use Case Scenario: 14 - Schedule travel


Test

Scenario: Schedule travel Users: Internal Volunteer

Description The Volunteer schedules travel arrangements


Assumptions


86

8.1.3.4 Use Case Scenario: 15 - Offer travel


Test

Scenario: Offer travel Users: Internal Volunteer

Description The Volunteers offer travel


Assumptions


8.1.4 Uses Cases related to Donor (only) not implemented

8.1.4.1 Use Case Scenario: 16 - Rate recipient


Test

Scenario: Rate recipient Users: Donor

Description The Donor rates the recipient


Assumptions


87

8.1.5 Use Cases related to Travel Intermediary only, not implemented

8.1.5.1 Use Case Scenario: 17 - Schedule transport


Test

Scenario: Schedule transport Users: Travel Intermediary

Description The Travel Intermediary schedules the transport


Assumptions


8.1.5.2 Use Case Scenario: 18 - Confirm arrangements


Test

Scenario: Confirm arrangements Users: Travel Intermediary

Description The Travel Intermediary confirms arrangements


Assumptions


88

8.1.6 Use cases related to Travel Intermediary and to Recipient not implemented

8.1.6.1 Use Case Scenario: 19 - Arrange transport


Test

Scenario: Arrange transport Users: Travel Intermediary, Recipient

Description The Travel Intermediary and the Recipient arrange transport


Assumptions


8.1.7 Use Cases related to Recipient only not implemented

8.1.7.1 Use Case Scenario: 20 - Register donation needs


Test

Scenario:

Register donation needs

Users: Recipient

Description The recipient registers the Donation Needs


Assumptions


89

8.1.7.2 Use Case Scenario: 21- Confirm receipt


Test

Scenario: Confirm receipt Users: Recipient

Description The recipient confirms the receipt of the Donation


Assumptions


8.1.7.3 Use Case Scenario: 22 - Rate donor


Test

Scenario: Rate donor Users: Recipient

Description The recipient Rates the donor


Assumptions


Documents

DELIVERABLE D.3.4 SavingFood Platform Prototype Evaluation The methodology to be followed for the technical evaluation is the “Product Quality Model” from ISO/IEC 25010:2011. A