Horizontal Requirement Engineering in Integration of Multiple IoT Use Cases of City Platform as a Service

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Horizontal Requirement Engineering
in Integration of Multiple IoT Use Cases
of City Platform as a Service
SecureEdge2017, Helsinki, Finland
Toshihiko Yamakami
IoT Business Unit, ACCESS
Toshihiko.Yamakami@access-company.com
2017/08
Toshihiko Yamakami (ACCESS Confidential)Horizontal Requirement Engineering in Integration of Multiple IoT Use Cases of City Platfo2017/08 1 / 24

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Outline
Background
Related Work
Research Method
Methodology for Horizontal Requirement Engineering
Interaction Identification
Coordination Identification
Impact Identification
Flow Model of Influence
Discussion
Advantages of the Proposed Model
Limitations
Conclusion

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Background
Research Purpose
The aim of this research is to develop a framework to deal with
combination of vertical IoT use cases.
Backgrounds
IoT requires combination of hardware, software, integration,
deployment and maintenance. This complexity leads to bias toward
vertical requirement engineering and technological silos.
Increased IoT deployment gradually exposes the difficulties in
combination of heterogeneous IoT systems
After initial successful IoT deployment, consideration of joint IoT use
cases bring intrinsic hard challenges of real-world IoT realization.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Related Studies and Research Method
Related Studies
a) heterogeneity of IoT systems: SOA-based scalable ubiquitous
systems[Chauvel12] federated discovery system[Gomes15] dynamic
service composition[Dar11]
b) lifecycle management of IoT systems: a system of
systems[Hefnawy16] DevOps experience[Stillwell15] DevOps
autoscaling[Fokaefs15] vertical silos in smart cities[Kubler16]
c) requirement engineering in IoT: interdisciplinary aspects[Knot16]
requirement engineering in smart cities[Aziz16]
The originality of this paper lies in its identification of a framework of
evaluation of joint IoT use cases.
Research Method:
compare the vertical and horizontal requirement engineering in IoT,
analyze a methodology to analyze impact of joint use cases in IoT,
present a checklist to raise awareness of impacts of joint use cases in
IoT.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Problems to be Solved
In IoT integration, there are two phases: initial vertical requirement
engineering and subsequent horizontal requirement engineering.
Harmonization in the second phase requires explicit awareness of
integrating multiple IoT use cases
A joint-use-case-aware specific requirement engineering methodology
is required for successful harmonization of multiple IoT systems.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Definitions
Term Description
Vertical requirement
engineering
It defines a set of requirements to a set of design using
a vertical model from use cases to integration in the
deployment-specific vertical view.
Horizontal require-
ment engineering
It defines a set of requirements to a set of design using
a horizontal model among independent vertical require-
ments.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
An example of vertical requirement engineering
Use cases
Requirements
Design
Architecture
Operation
Integration
Deployment
Software development
Hardware development
6
Requirement
Engineering
?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
An Example of Horizontal Requirement Engineering
Joint Use cases
Use cases
…
Hardware
development
Use cases
…
Hardware
development
…
Use cases
…
Hardware
development
Requirement Engineering -

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Overview of CPaaS.io
Smart City Innovation is the goal of the CPaaS.io joint RD project
between Europe and Japan starting from 2016.
To achieve this, the CPaaS.io platform combines the capabilities of
the Internet of Things (IoT), big data analytics and cloud service
provisioning with Open Government Data and Linked Data
approaches.
CPaaS.io hosts multiple projects in different cities in Europe and
Japan, e.g. Utrecht, Amsterdam, Tokyo, Sapporo, and Yokosuka.
URL: https://cpaas.bfh.ch/ CPaaS.io – City Platform as a Service

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Two Joint Use Case Patterns
-Use case
-
-
-
-
Joint
Use case -Req
-Dev -DepOpe
(a) Pre-development case
-Use case
-
-
-
-Req
-
-
-
-Dev
-
-
-
-DepOpe
-
-
-
-
Joint
Use case -Dev -
Additional
Dev -
Additional
DepOpe
(b) Inter-development case

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Existing Methods to Deal with Joint Use Cases
Method Description
Participatory design End users are involved in early stage of design as well as usual
requirement engineering.
Universal design Design follows the universality of ease of use.
Scenario-based design Scenarios are used to make concrete and visualize use scenes.
Agile development A loop of quick implementation and feedback is used to capture
and embed user requirements without heavy waterfall software
engineering.
Ad hoc integration Integration of different IoT services are performed in an ad hoc
manner.
Existing methods did not address the characteristics of horizontal requirement engineering.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Impacts of Joint Use Cases of IoT Services
Impact Description
Use case Combination of use cases leads to new use cases.
Software Requirements Combination of use cases leads to new requirements or amended
requirements of software.
API Combination of use cases leads to new APIs.
Architecture Combination of use cases leads to new architecture.
Privacy settings Combination of use cases leads to new privacy settings.
Security Combination of use cases leads to new security deployment.
Data Combination of use cases leads to new data management.
Performance Combination of use cases leads to new requirements of capacity,
throughputs, and turnaround time.
Hardware deployment Combination of use cases leads to new hardware deployment.
Operation Combination of use cases leads to new operation.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Framework to Deal with Joint Use Case Development
Interaction
identification
Coordination
identification
Impact
identification
- overlap
- interference
- conflicts
- isolated assumptions
-
- liason
- association
- isolation
- mapping
- discovery
-
- modification/
additoin of
use cases
- modification/
addition of systems,
deployment, and/or
operation

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Use Case Interaction Patterns
Interaction patterns
inclusion: the other is one’s subset
overlap: there is a shared and a non-overlapped parts among use cases
hidden diversity: there is hidden diversity in development, deployment,
and operation.
conflicting: requirements of different use cases have conflicts.
inclusion overlap hidden
diversity conflicting
This interaction needs to address each domain: requirements,
development, deployment, and operation.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Coordination Identification
Management of identification, liaison, association, and discovery
should be considered.
When applicable, coordinated development, deployment, and
operation are identified.
When the architectural design is stably established, this phase can be
just reconfirmation of architectural requirements.
Hidden aspects emerge and require revisits of overall design of
development, deployment, and operation.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Impact Identification
Impact Description
Use case Joint use cases lead to new use cases.
Software Requirements Joint use cases lead to new requirements or amended require-
ments of software.
API Joint use cases lead to new APIs.
Architecture Joint use cases leads to new architectural aspects.
Privacy settings Joint use cases lead to new privacy settings.
Security Joint use cases lead to new security deployment.
Data Joint use cases lead to new data management.
Performance Joint use cases leads to new requirements of capacity, through-
puts, and turnaround time.
Hardware deployment Joint use cases leads to new hardware deployment.
Operation Joint use cases leads to new operation.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Flow Model of Influence of Joint Use Cases
Use cases - Joint use cases
Consistency-
Impact on
-
-
integration
-
Unstable
requirement
feedback
inconsistency
Consistency :Joint use cases successfully landed in the existing integration cycle.
Unstable requirement feedback : Requirements create an unstable feedback loop which
impacts of quality of the integration cycle.
Impact on integration : Requirements amends requirements of each use case and impact
the following integration cycle with quality, cost and schedule issues.
Inconsistency : Requirements and subsequent impacts on integration cycle cannot be
resolved and lead to a patchy and unmanageable aggregation of requirements.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Impact Depth Analysis
Level Description
No impact No impact .
Minor impact Impacts are clarifications. They do not influence software, de-
ployment and operation schedule.
Requirement impact Single impact for requirements, which impact succeeding down-
stream process, including software design, software manufactur-
ing, hardware deployment, integration, and operation.
Single-thread software
impact
Single-thread impact for downstream software development and
integration.
Multiple requirement
impact
Multiple requirements from multiple use cases are impacted as
well as downstream processes including deployment, integration,
and operation.
Architectural impact Combination of use cases leads to amendment of architecture.
New interrelation man-
agement requirement
Combination of use cases leads to new requirements of interrela-
tion management, which impact all downstream processes.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A Checklist for each Relationship
Relationship Checklist
Inclusion Check if the larger will impact the other one.
Check if the larger part will be successfully managed by deploy-
ment, integration, configuration, or acceptance
Overlap Check if the differential parts at each side will impact the subse-
quent phases.
Check if the differential part at each side will be successfully man-
aged by deployment, integration, configuration, or acceptance.
Underlying diversity Check if the underlying diversity will impact the subsequent
phases.
Check if the underlying diversity will be successfully managed by
deployment, integration, configuration, or acceptance.
Conflicts Check how the conflicts will be resolved in the subsequent phases.
heck if the conflicts will be successfully managed by deployment,
integration, configuration, or acceptance.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Comparison
Method Pros Cons
Participatory
design
User acceptance at deployment is
high. User engagement is retained.
Feedback is easy.
Hardware-software integration is dif-
ficult to imagine at the early stages.
Impacts from large-scale deployment
are difficult to capture for end users.
Universal
design
Usability is high when it is suc-
cessfully implemented. Successful
blueprints are easy to deploy in dif-
ferent locations.
Universal design in IoT design is still
at its early stages and immature.
There are different factors such as de-
ployment and operation which are dif-
ficult to capture.
Scenario-
based
design
Users are easy to follow the scenarios
to imagine the use contexts.
Good scenarios are difficult to artic-
ulate. Interpretation of scenarios can
vary from user to user.
Agile devel-
opment
Useful for small-scale deployment and
verification. Also useful in open
source development environment.
Difficult to implement in large-scale
(size, time-scale and geolocation) de-
ployment.
Ad hoc inte-
gration
Investment costs are small without
detailed planning.
The outcome can vary from con-
text to context, depending on spon-
taneous skills of the participants.
The pro-
posed
method
With staged analysis of impacts, it is
useful to leverage awareness of mul-
tiple IoT stakeholders.
It is requirement-biased and requires
time-consuming real-world verifica-
tion.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Advantages of the Proposed Approach
The perspective of horizontal requirement engineering help facilitate
early awareness of challenges ahead of harmonization of potentially
closed systems.
The proposed method provides a framework to guide a proactive
attitude among different experts with different deployment-specific
issues. It visualizes the process view of horizontal requirement
engineering.
It is general and applicable to a wide range of IoT applications.
The classification of outcome of horizontal requirement engineering
serves a litmus test for integration of city-scale IoT platforms.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Limitations
This research is at its early stage. This paper is exploratory and
qualitative.
Detailed quantitative analysis of impacts remain for future study.
Dimensions described in this paper are not exhaustive.
Application-specific, location-specific, or technology-specific,
dimensions are not covered in this paper. Real-world examination of
the methodology remain for future study.
The presented checklist is not exhaustive. Detailed analysis of
checklists are not covered. Validation of real-world test cases are not
covered in this research. Long-term observation of impact of joint use
cases are out of scope of this paper.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
IoT involve hardware, software, deployment, integration, and
operation. This complexity easily leads to an isolated approach to
each case. There is an increasing need for considering joint use cases.
The author proposes a methodological framework to deal with this
challenge. The author analyzes an impact model of joint use cases.
Then, the author presents a flow model of considering joint use cases
to clarify the impact relationship in the horizontal engineering. Third,
the author presents a checklist of horizontal engineering.
The full potential of IoT lies in the harmonization of multiple vertical
requirement engineering In order to harness the second phase
requirement engineering to deal with joint use cases, it is necessary to
explore a systematic methodology to leverage awareness of challenges
of considering joint use cases.
There are natural isolation assumptions in IoT use cases, which lead
to potential sources of conflicts in future development of joint use
cases. The proposed method is a stepping stone to parse the
challenges of horizontal engineering.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Thank you for your attention!
Questions?

Horizontal Requirement Engineering in Integration of Multiple IoT Use Cases of City Platform as a Service

More Related Content

What's hot

Similar to Horizontal Requirement Engineering in Integration of Multiple IoT Use Cases of City Platform as a Service

More from Toshihiko Yamakami

Recently uploaded

Horizontal Requirement Engineering in Integration of Multiple IoT Use Cases of City Platform as a Service