Coverage Analysis

5.1 Coverage Analysis

In the following sections the requirements that are affected by each of the use cases described above are identified. This will not only serve to identify where the different requirements come from, but also to point out where they will be validated once the developments are completed.

In order to keep this document minimal, the following analysis does not list all details of the requirements but limits itself to the requirement identifier and the description. The complete description of the different requirements can be found in annex A of D1.1 [D11].

To simplify the matching between the use case specification and the requirements specification, the coverage analysis reuses the requirements classes introduced in the requirements specification. Consequently, we first discuss the general requirements and thereafter, we discuss the other classes that are specific to one of the research and development work packages.

5.1.1 General Requirements

As described in the requirements specification, the general requirements are those requirements that are either targeting all parts of the work or that can only be realized jointly. The following table contrasts these requirements with the use cases introduced previously.

1 .1 .2 M M M M

Requirements vs. Use Cases and Scenarios

U U U U U U U GE_001. The GAMBAS framework should be able to √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

support different devices. GE_004. The GAMBAS framework provides crowd-levels

√ √ √ √ √ for each bus journey.

GE_005. The GAMBAS framework running on mobile devices should be implemented in Java or provide Java √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ interfaces. GE_007. The GAMBAS framework enables providing √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ adaptive and customized information to users. GE_008. The GAMBAS framework simplifies the development of services that acquire data from

√ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ different devices. GE_009. The GAMBAS framework enables the

√ √ √ √ √ √ √ √ √ √ √ development of composed services.

GE_010. The GAMBAS framework enables the √ √ √ √ √ √ √ √ √ √ √ √ √ √ optimization of services based on usage behavior.

M M 1 E 2 E E E 1 E .1 .2 .1 3 E .1 E 4 .1 5 E 6 E

Requirements vs. Use Cases and Scenarios

GE_011. The GAMBAS framework enables proactive √ √ √ √ √ √ √ √ √ √ √ √ √ √ service offerings based on the current user context.

GE_012. The GAMBAS framework enables users to protect their privacy by controlling the sharing of √ √ √ √ √ √ √ √ √ √ √ √ √ √ acquired data. GE_013. The GAMBAS framework should enable the √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ acquisition of travel- and environment-related data. GE_014. The application services are able to compute √ √ √ √ √ √ √ possible end-to-end bus routes. GE_015. The application services are able to aggregate

√ √ √ and share crowd levels from busses.

GE_016. The GAMBAS framework enables providing environmental quality data for a geolocated point in the

√ √ √ √ √ √ √ √ √ city. GE_017. The application services are able to record and

predict crowd-levels. GE_018. Personal devices should have internet access to retrieve data from social networks and collaboration

√ √ tools. GE_019. The application services are able to aggregate

√ √ √ √ √ √ √ √ √ and share environmental information.

Table 20 – General Requirements Coverage Matrix

The general requirements include needs that affect the entire project as a whole. Therefore, it is natural to find several requirements that are actually covered or motivated by all use cases (GE_001 and GE003). In general, all requirements are treated in a high number of uses cases, with the only exception of the use cases addressing specific features of only one of the domain of application, as GE004 that is quite specific to the use cases dealing with the data retrieved to measure the number of passengers in a bus.

Thus, it is natural to find a clear difference between the last set of requirements (GE014 to GE019). The mobility scenario is affected by requirements GE_014, GE_015 and GE_017, whilst the environmental scenario is affected by GE_019. Only GE_015 participates in both scenarios, since the metric “number of passenger in each bus” appears in UC05M, UC05.1M and UC06E.

From the point of view of the use cases, the most complex ones – at least analyzing the number of requirements covered – are UC05M, UC05.1M and UC06E. On the other hand, UC01M, UC02E and UC04E and UC04E, are the ones affected by the lowest number of requirements. This does not reflect the importance of those use cases – especially UC01M and UC02E – but rather the fact that they are the basic use cases describing the two scenarios.

5.1.2 Adaptive Data Acquisition

The adaptive data acquisition requirements affect primarily the data acquisition framework developed by the project as well as the data acquisition component that are used to support the specific application prototypes developed to validate the project’s success. The following table

contrasts these requirements with the use cases introduced previously.

E E E E E E E M .1 .2 M M M M .1 M 1 M 2 3 4 5 6 7 1 2 .1 3 .1

.1 E E

Requirements vs. Use Cases and Scenarios

AA_001. The data acquisition framework shall allow √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ multimodal data acquisition. AA_002. The data acquisition framework shall be √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ extensible. AA_003. The data acquisition framework shall allow √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ automated acquisition of context data. AA_004. The data acquisition framework shall be

√ √ √ √ lightweight.

AA_005. The data acquisition framework shall be able √ √ to classify audio data.

AA_007. The data acquisition framework shall enable energy efficient context recognition for several

√ √ √ √ √ √ √ applications. AA_009. The data acquisition framework shall provide a √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ control interface to the privacy framework. AA_012. The data acquisition framework shall allow optimization of context recognition components by

√ √ √ allowing configurable parameters. AA_013. The data acquisition framework shall provide tools to simplify the offline training for recognizing

√ √ different types of context. AA_014. The activity recognition components must be

able to capture the past user locations in an energy- √

efficient manner. AA_015. The intent recognition components are able to

predict the next location of a user. AA_016. The localization performed by the activity recognition components should not expose the user's

√ √ location to untrusted third parties. AA_017. The activity recognition components must be

√ √ √ √ √ √ able to capture the mode of locomotion.

AA_018. The intent recognition components are able to √ √ √ predict the stay duration of the user.

AA_019. The data acquisition framework shall allow the reuse of components to recognize different types of

√ √ context.

M M 1 E E E E 1 E .1 .2 2 3 4 5 .1 6 7 2 .1

2 3 .1 4 E .1 E 5 E Requirements vs. Use Cases and Scenarios 6 0 1 1 5 0 0 0 3 0 4 0 0

UUU AA_020. The sound recognition components shall

enable the classification of different environmental √ √ sounds. AA_021. The speech recognition components support √ √ √ √ √ √ √ √ server-less operation with a limited vocabulary. AA_022. The data acquisition framework shall provide tool support to simplify the development of new

√ √ √ methods to recognize context. AA_023. The intent recognition component must record

context histories in a storage-efficient manner. AA_024. The data acquisition framework must be able

to record and predict a user's travel behavior. AA_025. The data acquisition framework must be able to record and predict co-use of public transport by

friends. AA_026. The data acquisition framework should provide an API to discover the types of data that are used to

√ √ √ √ √ √ derive other data.

Table 21 – Adaptive Data Acquisition Coverage Matrix

There are three requirements covered in all use cases (AA_001, AA_002 and AA_003). These are generic requirements describing the core of the data acquisition framework functionalities, and therefore they will be addressed in any scenario at the project. On the other hand, AA_014, AA_015, AA_023, AA_024 and AA_025 are exclusively addressed by the prediction use case (UC02M). This could actually be extended to other use cases making use of the prediction feature too. However, in the way the use cases have been formulated, the requirements are currently just affected by this single use case.

From the point of view of the use cases, it is the prediction feature the one that requires more attention – with one of the highest number of requirements. The other use case with a high level of requirements covered is UC02E, which makes sense since in order to establish a pollution map, data acquisition will play a key role.

5.1.3 Automated Privacy Preservation

The requirements on automated privacy preservation affect primarily the privacy preservation framework and mechanisms as well as the policy and the associated generation tool. The following table contrasts these requirements with the use cases introduced previously.

M M M E E E Requirements vs. Use Cases and Scenarios 1 .1 .2 M 2 M 3 4 M M M 5 .1 6 M M E 1 7 E 2

2 .1 3 E 3 .1 E 4 .1 E 5 E 0 6 1 1 0 0 0 0 5 0 0 0 0 0 0 4 0 0

PP_002. Sensible context should be kept private and √ √ √ √ √ √ √ should not be available publicly. PP_003. The (wireless) transfer of context should be √ √ √ √ √ √ √ secured. PP_005. The derived privacy policies should be

accessible even when there is no internet connection. PP_006. The privacy preservation framework needs to

be lightweight such that it can be executed on resource- √ √ √ √ poor devices. PP_007. Any third party that stores or processes √ √ √ √ √ context should be authenticated. PP_008. It should not be possible for an application to access context without involving the privacy √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ components. PP_009. The privacy preservation framework should be extensible with regard to other data sources for the √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ privacy policy generation. PP_010. Conflicts in the privacy settings of social networks should be detectable by the privacy √ √ √ preservation framework. PP_011. The resulting privacy policy should be able to

√ √ generalize context.

PP_012. The privacy policy generation tool should support the user by suggesting solutions to conflicted √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ settings. PP_013. The privacy preservation framework must enable the exploitation of trust relationships between √ √ √ users. PP_014. The privacy preservation framework must allow users to share selective aspects of their travel √ √ behavior with friends.

Table 22 – Automated Privacy Preservation Coverage Matrix

The privacy framework is one of the core components of the project. Therefore we can find that some of the requirements describing its expected functionality are actually motivated by a high number of use cases (PP_008, PP_009 and PP_012). At the same time, other requirements are very specific to some of the functionalities required by the different use cases (PP_005, PP011 and PP014).

From the point of view of the use cases, a low number of them are imposing most of the requirements (UC01M, UC02M and UC01E). These are indeed the use cases that describe the scenarios closest to the GAMBAS approach with regards to privacy preservation. On the other side, a From the point of view of the use cases, a low number of them are imposing most of the requirements (UC01M, UC02M and UC01E). These are indeed the use cases that describe the scenarios closest to the GAMBAS approach with regards to privacy preservation. On the other side, a

5.1.4 Intent-aware User Interface

Intent-aware user interface requirements primarily affect the user interfaces that are visible to a citizen. The following table contrasts these requirements with the use cases introduced previously.

Requirements vs. Use Cases and Scenarios

U U U U U U C U C U C U U U U U UI_005. The user interface performs proactive

recommendations on trips. UI_006. The user interface enables the user to manually override and limit automated collection and sharing of √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ data. UI_007. The privacy setting should indicate a distinction √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ between on device and on the server. UI_008. The personal user interfaces support the √ √ √ √ √ √ √ √ √ visualization of possible routes. UI_009. It should be possible to manually configure the √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ policy. UI_010. The user interface component must enable √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ users to select privacy preferences. UI_011. The user interface component must √ √ √ √ √ √ √ √ recommend personalized transport routes. UI_012. The user interface component must provide

personalized information related to user intent. UI_013. The user interface component should enable √ √ √ √ √ users to become aware of friend's travel behavior. UI_014. The user interface should anticipate user information needs and be designed to minimize user √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ input. UI_015. The user interface should be designed to √ √ √ √ √ √ √ √ improve user's feeling about public transport.

Table 23 – Intent-aware User Interface Coverage Matrix

The user interface will be the front end to interact with citizens within the smart city. Thus, all the requirements that affect such interaction are covered in all use cases (UI_006, UI_007, UI_009 and UI010). On the other hand, there are a couple of requirements that exclusively affect one of the prediction use case (UC02M).

From the point of view of the complexity of the use cases – considering the number of requirements to be covered – the most challenging one is, once again UC02M, the prediction use case. All in all, the use cases from the mobility scenario are affected by a higher number of requirements than the From the point of view of the complexity of the use cases – considering the number of requirements to be covered – the most challenging one is, once again UC02M, the prediction use case. All in all, the use cases from the mobility scenario are affected by a higher number of requirements than the

5.1.5 Interoperable Data Representation and Query Processing

The requirements on interoperable data representation and query processing primarily address issues related to ensuring data interoperability as well as enabling the discovery and processing of static and continuously changing data. The following table contrasts these requirements with the use cases introduced previously.

M M M M M E E E E E E E .1 .2 .1 M M 4 .1 1 E 2 .1 3 .1 E 5 6

Requirements vs. Use Cases and Scenarios

DQ_001. The data representation must provide a unified view of the data among connected devices and √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ services. DQ_002. The processing and query execution system √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ should support dynamic discovery of data. DQ_003. Basic data storing and processing will be √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ provided for constrained computer systems (CCS).

DQ_004. The data processing should be able to adapt to √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ changes in the network and incoming data. DQ_005. The data representation and query language √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ should be generic. DQ_006. The data representation must support spatial √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ data in different formats. DQ_008. The data processing framework should cope √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ with intermitted disconnections. DQ_009. The data processing framework should be √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ V √ √ √ scalable. DQ_010. The linked data discovery infrastructure does not require the user to expose a particular type of √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ information. DQ_011. The data representation should provide a data √ √ √ √ √ √ √ √ √ v √ √ √ √ √ √ √ √ √ model for the information relevant to the use cases.

DQ_012. The data representation should be extensible. √ √ √ √ √ √ √ √ √ v √ √ √ √ √ √ √ √ √ DQ_013. The data processing framework supports √ √ √ √ √ √ √ √ √ v √ √ √ √ √ √ √ √ √ continuous queries on changing data. DQ_014. The data representation and query processing √ √ √ √ √ √ √ √ √ v √ √ √ √ √ √ √ √ √ framework should be interoperable. DQ_016. The data representation should provide √ √ √ √ √ √ √ √ √ v √ √ √ √ √ √ √ √ √ support for context generalizations. DQ_017. Large data storage and advanced query processing will be provided in back-end computer √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ systems (BCS) or traditional computer systems (TCS).

M M M M E M M M M M M 1 E E 2 .1 3 E E E E E E

U U U U C U U U U C C C C C C U C U U U U U U U U U DQ_018. The data representation should be based on √ √ √ √ √ √ √ √ √ v √ √ √ √ √ √ √ √ √

Requirements vs. Use Cases and Scenarios

linked data principles. DQ_019. Stream processing will be provided in back- √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ end computer systems or traditional computer systems. DQ_020. Basic RDFS reasoning will be supported on the √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ stream processing.

Table 24 – Interoperable Data Representation and Query Processing Coverage Matrix

As expected, the semantic components are part of the core of the project, and therefore, their requirements are highly covered or motivated by almost all use cases.