Open innovation is becoming an important strategy in software development. Following this strategy, software companies are increasingly opening up their platforms to third-party products. However, opening up software platforms to third-party applications raises serious concerns about critical quality re-quirements, such as security, performance, privacy and proprietary owner-ship. Adopting appropriate openness design strategies, which fulfill open-innovation objectives while maintaining quality requirements, calls for delib-erate analysis of openness requirements from early on in opening up soft-ware platforms. We propose to treat openness as a distinct class of non-functional requirements, and to refine and analyze it in parallel with other design concerns using a goal-oriented approach. We extend the Non-Functional Requirements (NFR) analysis method with a new set of cata-logues for specifying and refining openness requirements in software plat-forms. We apply our approach to revisit the design of data provision service in two real-world open software platforms and discuss the results.

1. Accommodating Openness
Requirements in Software Platforms
Mahsa H. Sadi and Eric Yu
1
Department of Computer Science
University of Toronto
A Goal-Oriented Approach
CAiSE 2017, June 14th, Essen, Germany

2. Open Innovation: Software companies open up
their platforms to 3rd party applications
Open Platforms: Platforms on top of which
3rd party applications can be built
Extension mechanisms allow sufficient access
2
Background
Boudreau, K. (2010). Open platform strategies and innovation: Granting access vs.
devolving control. Management Science, 56(10), 1849-1872.
Fitzgerald, B. (2006). The transformation of open source software. MIS Quarterly, 587-598.
West, J. (2003). How open is open enough?: Melding proprietary and open source plat-
form strategies. Research policy, 32(7), 1259-1285.

3. 3
Example – Mobile Platforms

4. 4
Other Examples of Open Platforms

5. Opening up software platforms is
a difficult transition
Openness requirements pose serious risks to:
Security, Performance, Controllability
Problem Statement - 1
5
Boudreau, K. (2010). Open platform strategies and innovation: Granting access vs. devolving
control. Management Science, 56(10), 1849-1872.
Scacchi, W., & Alspaugh, T. A. (2013). Processes in securing open architecture software
systems. In Proceedings of International Conference on Software and System Process.
Baresi, L., Di Nitto, E., & Ghezzi, C. (2006). Toward open-world software: Issue and
challenges. Computer, 39(10), 36-43.
West, J. (2003). How open is open enough?: Melding proprietary and open source plat-form
strategies. Research policy, 32(7), 1259-1285.

6. Example Problems in Open Platforms -1
6
WikiLeaks Press Release – March 7, 2017

7. Example Problems in Open Platforms -2
7
WikiLeaks Press Release – March 7, 2017

8. 8
The Proposed Approach
• Treat openness as a distinct class of
non-functional requirements
• Refine openness requirements
in parallel with competing design concerns
Using a goal-oriented modeling approach
Sadi, M. H. & Yu, E. (2017).
Modeling and analyzing openness trade-offs in
software platforms: a goal-oriented approach.
In REFSQ 2017.

9. 9
Contributions of this Study
Extending the Non-Functional
Requirements analysis framework with:
Openness Catalogues
Alternative paths for specifying
and refining openness requirements
Chung, L., Nixon, B. A., Yu, E., & Mylopoulos, J. (2000). Non-functional requirements in
software engineering. Springer Science & Business Media.

10. 10
The Outline of the Rest of the Talk
1. Proposed Openness Catalogues
2. Using the Proposed Catalogues

11. 11
Proposed Openness Catalogues
Openness Catalogues
Openness
Requirements Catalogues
Openness
Operationalziation
Catalogues
Openness
Correlation Catalogues

12. 12
1. Openness Requirements
Specification and Refinement Catalogues

13. 13
Openness Requirements Catalogues
Openness
Requirements Catalogues
General
Design
Requirements
Business-Level
Openness
Requirements
System-Level
Openness
Requirements

14. The technical and quality
requirements for openness
Openness Catalogues
14
System-Level Openness Requirements
Accessibility [Platform]
Accessibility
[Data]
...Accessibility
[Functionality / Service]
Help Help Help
Openness [Platform]
Accessibility
[Platform]
Extensibility
[Platform]
HelpHelpHelp
...
[1] [2]
[1] Anvaari, M., & Jansen, S. (2010). Evaluating
architectural openness in mobile software platforms. In
Proceedings of 4th ECSA: Companion Volume.
[2] Bosch, J., & Bosch-Sijtsema, P. (2010). From
integration to composition: On the impact of software
product lines, global development and ecosystems. JSS. Extensibility [Platform]
Composability
[Platform]
Decoupling
[TP APP]
Development
A synchronization
[TP APP]
Stability
[Platform]
Help HelpHelp
Help Help
...

15. The non-technical requirements
driving the need for openness
Their relation to system-level
openness requirements
Openness Catalogues
15
Business-Level Openness Requirements
[1] Popp, K. M. (2010). Goals of Software Vendors for
Partner Ecosystems–A Practitioner´ s View. In Software
Business (181-186).
Partner Ecosystem Gravity
[Platform]
Adoptability
[Platform]
Help
Help Openness
[Platform]
Help
Network Effect Objectives
Help
Accessibility
[Platform]
[1]

16. General concerns raised
in opening up platforms
e.g. Security
Openness Catalogues
16
General Design Concerns
[1] Chung, L., Nixon, B. A., Yu, E.,
& Mylopoulos, J. (2000). Non-functional
requirements in software engineering.
Springer Science & Business Media.
Security [Platform]
Availability
[Platform]
Accuracy
[Platform]
Integrity
[Platform]
...
Consistency
[Data]
...
Value Accuracy
[Data]
...
Help Help Help
Help Help
HelpHelp Help
[1]

17. 17
2. Openness Operationalization Catalogues

18. • The specific features and functionalities
designed for openness
• Alternative mechanisms and patterns
to design these functionalities
Openness Catalogues
18
Operationalization Catalogues

19. 19
Openness Catalogues
Design Objective:
To provide data service to third-party applications
Decisions about:
• How platform communicates data
with 3rd party applications
• How 3rd party applications
communicate data with each other
Operationalization Catalogues – Example (1)

20. Openness Catalogues
20
Operationalization Catalogues – Example (2)
Design Objective: To provide data service 3rd party applications
Design 1: (CDP): Centralized Data Provision [1]
The platform controls all data and information interactions …
Design 2: (SDP): Semi-Centralized Data Provision [2]
3rd party applications can communicate data directly in some cases…
Design 3: (DDP): Decentralized Data Provision [3]
3rd party applications can directly exchange data …
[1] Eklund, U., & Bosch, J. (2014). Architecture for embedded open software ecosystems. JSS.
[2] Shabtai, A., Fledel, Y., Kanonov, U., Elovici, Y., Dolev, S., & Glezer, C. (2010). Google android: A
comprehensive security assessment. IEEE Security & Privacy.
[3] Scacchi, W. (2007). Free/open source software development: Recent research results and
methods. Advances in Computers.

21. 21
3. Openness Correlation Catalogues

22. Reasoning about
the impact of
design alternatives
on the requirements
Openness Catalogues
22
Correlation Catalogues
Sadi, M. H., & Yu, E. (2017). Modeling
and analyzing openness trade-offs in
software platforms: a goal-oriented
approach. In REFSQ 2017. Semi - centralized
data provision
Decentralized
data provision
Hurt ...
Centralized
data provision
Provide Data
...
...
Help
Security
[Platform]
Accessibility
[Platform] ...
Consistency
[TP App Data]
...
...
...
Accessibility
[Platform Data]
Accuracy
[Platform Data]Help
Help
Help
Help
Help
Integrity
[Platform Data]
Help
Openness
[Platform]
Help

23. Openness Correlation Catalogues
23
Composability
[Platform]
Decoupling
[TP APP]
Help
Deployability
[TP App]
Help Help
Independent
Deployment
[TP App]
Semi - centralized
data provision
Decentralized
data provision
Help
Independent
Behaviour
[TP App]
Security
[Platform]
Consistency
[Data]
Openness
[Platform]
Accessibility
[Platform]
Extensibility
[Platfrom]
Centralized
data provision
Isolatability
[TP App Data]
Help
Ownership
[Platform]
Ownership
[Platform
Data]
Performance
[Platform]
Access
time
[Data]
Help
G: Provide Data
Response
Time
[Platform]
Confidentiality
[Platform
Data]
Confidentiality
[TP App
Data]
Accuracy
[Data]
Accessibility
[Platform
Data]
Integrity
[Platform
Data]
Isolatability
[Platform
Data]
Help
Help
Help
HelpHelp
Help
Help
Help
Help
Help
Network Size [Platform]
Stickiness
[Platform]
Market Presence
[Platform]
Software Vendor
Offering [Platform]
Help Help Help
Market reach
[Platform]
New market
[Platform]
New community
[Platform]
HelpHelp Help
HelpHelp
Innovative Features [Platform]
Help Help
Operational
Security
[Platform]
Availability
[TP App
Data]
Help
Hurt
Help
Adoptability [Platform]
Partner Ecosystem
Gravity [Platform]
Help
Help
Privacy
[Platform
Data]

24. 24
The Outline of the Rest of the Talk
1. Proposed Openness Catalogues
2. Using the Proposed Approach

25. •An open mobile platform
•An open automotive platform
Applying the Proposed Approach
25

26. An Operating system for mobile platforms
Functionalities: Controlling the operations of
smartphone devices
Open to a wide variety of 3rd party applications
The Case Under Study
26
An Open Embedded Mobile Platform
Objective: Revisiting the Data Provision Service
Using the Proposed Approach

27. An Open Embedded Mobile Platform
27
Design Requirement Text Description
... …
“Low
Entry Barriers”
Priority: “High”
“Entry barriers of both monetary and
technical nature, including entry barriers for
application market, development resource
needs and programing languages, will be a
significant factor for developers in selecting
which mobile platform to join.”
Koch, S., & Kerschbaum, M. (2014). Joining a smartphone ecosystem: Application developers’
motivations and decision criteria. Information and Software Technology, 56(11).
Openness Design Requirements

28. An Open Embedded Mobile Platform
28
Design Requirement Text Description
***Privacy [data]
| Priority: Medium
Privacy of 3rd party application data
… ….
Other Design Requirements

29. Open Embedded Mobile Platform
29
Using the Proposed Catalogues
• To refine the design requirements
• To analyze alternative design mechanisms
• To identify an appropriate design
mechanism

30. An Open embedded Mobile Platform
30
“Low
Entry Barriers”
Priority: “High”
“Entry barriers of monetary and technical nature…”
Refining Design Requirements - Example
Composability
[Platform]
Decoupling
[TP APP]
Help
Accessibility
[Platform]
Extensibility
[Platfrom]
Accessibility
[Platform Data]
Help
Openness
[Platform]
Help
Security
[Platform]
Isolatability
[TP App Data]
Isolatability
[Platform Data]
Help
Help
Privacy
[Platform Data]
Help

31. Open Mobile Software Platform
31
Analyzing Alternative Design Mechanisms
Semi - centralized
data provision
Decentralized
data provision
Hurt Help
Centralized
data provision
Provide Data
Composability
[Platform]
Decoupling
[TP APP]
Help
Security
[Platform]
Accessibility
[Platform]
Extensibility
[Platfrom]
Isolatability
[TP App Data]
Performance
[Platform]
Access time
[Data]
Response Time
[Platform]
Accessibility
[Platform Data]
Isolatability
[Platform Data]Help
Help
Help
Help
Help
Privacy
[Platform Data]
Help
Openness
[Platform]
Help

32. Open Mobile Software Platform
32
Analyzing Alternative Design Mechanisms
Composability
[Platform]
Decoupling
[TP APP]
Help
Deployability
[TP App]
Help Help
Independent
Deployment
[TP App]
Semi - centralized
data provision
Decentralized
data provision
Help
Independent
Behaviour
[TP App]
Security
[Platform]
Consistency
[Data]
Openness
[Platform]
Accessibility
[Platform]
Extensibility
[Platfrom]
Centralized
data provision
Isolatability
[TP App Data]
Ownership
[Platform]
Ownership
[Platform
Data]
Performance
[Platform]
Access
time
[Data]
Help
G: Provide Data
Response
Time
[Platform]
Confidentiality
[Platform
Data]
Confidentiality
[TP App
Data]
Accuracy
[Data]
Accessibility
[Platform
Data]
Integrity
[Platform
Data]
Isolatability
[Platform
Data]
Help
Help
Help
HelpHelp
Help
Help
Help
Help
Help
Help
Market reach
[Platform]
New market
[Platform]
New community
[Platform]
HelpHelp Help
Innovative Features [Platform]
Help Help
Hurt
Adoptability [Platform]
Partner Ecosystem
Gravity [Platform]
Help
Help
Privacy
[Platform
Data]
✔
✔ ×
××
×
×
×
✔
✔ ✔
✔
✔ ×
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
×
×
×
×
×
×
×
×
× ✔ ✔
✔
✔
×
×
×
×
×
×
✔
✔
✔
✔
✔ ✔✔
✔ × × ✔ ✔ × × ✔ ✔
✔ × × ✔ × ×
✔ × ×
✔ × ×
× ✔ ✔
! !
!
!!
!!
!!
!
CDP: Centralized data provision SDP: Semi-centralized data provision DDP: Decentralized data provision
Left-Most Evaluation Labels Middle Evaluation Labels Right-Most Evaluation Labels

33. Requirements Security Openness: System-Level Performance
*Privacy Accessibility *Composability … *Response Time
Priority *Medium High *Medium *High
CDP PSat PDen PSat … PDen
SDP PSat PSat PDen PSat
DDP PDen PSat PDen PSat
An Open Mobile Software Platform
33
The Most Appropriate Design Mechanism
Semi-Centralized data provision is the best
design mechanism
PDen: Partially Denied PSat: Partially Satisficed

34. Requirements Security Openness: System-Level Performance
*Privacy Accessibility *Composability … *Response Time
Priority *Medium High *Medium *High
SDP PSat PSat PDen PSat
An Open Mobile Software Platform
34
Deciding about the design mechanism
Composability
[Platform]
Decoupling
[TP APP]
Help
Deployability
[TP App]
Help Help
Independent
Deployment
[TP App]
Independen
t Behaviour
[TP App]
Openness
[Platform]
Extensibility
[Platform]
Help

35. 35
Summary - 1
Objective:
To provide a systematic treatment for dealing with
openness requirements
Proposed Solution:
1. Consider openness as a distinct class of non-
functional requirements
2. Refine it in parallel with other design concerns
Openness catalogues that facilitate reasoning
about openness requirements

36. The benefit of the proposed approach:
To detect potential conflicts
Between openness and other critical
requirements
To help identify openness design mechanisms
That balance the fulfillment of openness
requirements against other critical requirements
Summary - 2
36

37. 37
Future Work
1. To extend the content of
the proposed catalogues
2. To assess the effectiveness of the
proposed approach in case studies
of open platform projects

38. 38
E-mail: mhsadi@cs.toronto.edu