Pervasive computing systems are complex and challenging. In this research, our aim is to build a robust reference architecture for pervasive computing derived from real business needs and based on process re-engineering practices. We derived requirements from different sources grouped by selected quality features and worked on refining them by identifying the conflicts among these requirements, and by introducing solutions for them. We checked the consistency of these solutions across all the requirements. We built a mathematical model that describes the degrees of consistency with the requirements model and showed that they are normally distributed within that scope. Full paper: https://www.researchgate.net/publication/316582796_A_Statistical_Approach_to_Resolve_Conflicting_Requirements_in_Pervasive_Computing_Systems?_iepl%5BviewId%5D=GYzOmb1HA01ScDf1IJ1T8eif&_iepl%5BprofilePublicationItemVariant%5D=default&_iepl%5Bcontexts%5D%5B0%5D=prfpi&_iepl%5BtargetEntityId%5D=PB%3A316582796&_iepl%5BinteractionType%5D=publicationTitle Citation Osama M. Khaled, Hoda M. Hosny, Mohamed Shalan (2017). A Statistical Approach to resolve conflicting requirements in pervasive computing systems. The 12th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2017), Porto, Portugal, 28-29 April 2017.

1. A Statistical Approach to Resolve Conflicting
Requirements in Pervasive Computing Systems
By
Osama Mabrouk Khaled

2. What is Pervasive Computing?
• 3rd Computing Paradigm
• Distributed Computing,
Mobile Computing,
Embedded Systems,
Autonomic and
Computing HCI shaped it
• Known by
• Sensors
• Actuators
• Mobility
• Context-Awareness
• Adaptability

3. - By 2020, the number of objects
connected to the Internet will be
about 50 billion
- Cisco expects the economy to
reach $14.4 billion by 2025
- 40% out of 450 surveyed IT and
business leaders expect that
pervasive computing will boost
sales and cut cost within 3 years
- Huge data gathering with accuracy
- Software enabled-devices are
easier to manage
Refs: Cisco, Gartner
Importance of Pervasive Computing

4. What is Software Engineering?
Requirements
and Analysis
Design
ImplementTest
Deploy Maintain

5. What is A Reference Architecture?
Reference Architecture
Best Practices
Guidelines
Models
Documentation
Practical
experience
Patterns

6. Software Engineering + Architecture
Requirements
and Analysis
Architecture Design Implement
TestDeployMaintain
Reference Architecture Software Architect

7. Approach
High Level
Review Business
Reference Architecture
Architect
Or
Business Analyst
Review Technical
Reference Architecture
Generate a concrete
architecture
We organized the PervCompRA-SE so that
the architect or the business analyst can
use the business reference architecture
then proceed with the normal activities to
generate a concrete architecture. On the
other hand, the architect or the business
analyst may proceed to review the
technical reference architecture then
proceed to generate the concrete
architecture.

8. Process Re-engineering
In process re-engineering, there are 3 major objectives that the
engineer must do [21] [22]:
1. Maximize the value added tasks that the customer is willing
to pay for.
2. Minimize the non-value added tasks which are essential for
the process but the customer will not be willing to pay for.
3. Eliminate tasks that are considered a clear waste in the
process.

9. Business Reference Architecture
Requirements Modeling
Minimize: it is a relationship in
which one requirement works on
minimizing a non-desired issue
from another piece of requirement.
Maximize: it is a relationship in
which one requirement works on
maximizing a desired value from
another piece of requirement
Conflict: it shows that two
requirements could have conflicting
values. If this happens, then one of
them must supersede the other in
order to resolve this conflict. The
relation could be uni-directional or
bi-directional.
<<minimize>>
<<maximize>>
<<conflict>>
Requirement 1 Requirement 2
Requirement 1 Requirement 2
Requirement 1 Requirement 2
+Superseding

10. Related Work – State of the Art
• The reviewed research efforts focus mostly on
the context as the main driver.
• Conflict resolution efforts were mostly directed
towards conflict identification and used simple
resolution strategies where one requirement
would have to be eliminated.
• There are no statistical approaches to resolve
the conflicting requirements with balanced
solutions.
Requirements Engineering and Conflict
Identification and Resolution

11. Requirements Engineering
Quality Features
Service
Omnipresence
Invisibility Context
Sensitivity
Adaptable
Behavior
Experience
Capture
Heterogeneity
of Devices
Fault
Tolerance
Security
Quality of
Service
Privacy and
Trust
Safety
• Detailed explanation of
the quality feature
• 56 Requirements
• 9 UC
• 6 SM
• Validated/Refined in a
workshop with 4
experts.

12. Quality Features
Feature Description Type
Adaptable
Behavior
The system must be capable of dynamically responding to changes in the
environment as needed [14].
B
Context
Sensitivity
The system must have the ability to sense and retrieve data from its
environment [14].
B
Experience
Capture
The system must be able to capture and register experiences for later use
[14].
B
Fault Tolerance The system must be able to detect errors and take the appropriate
recovery actions [14].
B
Heterogeneity of
Devices
The system must be able to use different device technologies seamlessly
[14].
B
Invisibility The system must integrate computing resources and guarantee that the
user has the minimum awareness of them [14].
B
Privacy and Trust The system must ensure that personal operations confidentiality is
protected and accessed only by trusted entities [14].
B
Quality of Service The system must set expectation for its services by setting constraints on
the provided services. For example, system response may be considered
invalid if it is received after a certain period of time [14].
B
Safety The system must ensure highest healthiness of its hardware and provide
immunity for its users and interacting devices from harm and damage.
B
Security It is concerned with protecting data from being leaked to unauthorized
individuals, protecting data from corruption and alternation, and ensuring
accessibility to data whenever requested.
B
Service
Omnipresence
The system should give its users the feeling that they carry computer
services wherever they move [14].
B

13. Requirements Engineering
Context Sensitivity (Example)

14. Tradeoff Analysis
1. Reviewed all the requirements of the business quality
features and defined maximize, minimize, and conflict
relationships whenever applicable.
2. Generated relationships among the quality features using
maximize, minimize, and conflict relationships.
3. Defined weights for the quality features based on their
complexities ( requirements x relations x features).
4. Validated the results of the complexity weights using a
survey with 17 experts. The results showed very close
ranking.
5. Validated the conclusions of the tradeoff analysis with a
similar exercise by Spinola and Travassos. The comparison
showed almost the same conclusions.

15. Tradeoff Analysis
Requirements Relationships
Source Name Destination Name Notes Why Superseding
Use a unique user
identifier
(Superseding)
Provide a unique
identifier for every
object
a user may have more
than one device joining
the pervasive system,
which may confuse the
system and lead it to
make multiple
identifications for the
same user.
having a unique user
identifier will ensure
that different rules
associated with it are
cascaded properly for
devices associated
with him/her
Source Name Destination Name Notes
Distribute computing
power
Capture Knowledge
about users
distributed computer power, including sensors,
can capture more information about users
including their habits, movement patterns, and
routine actions within the space of the smart
environment
maximize
conflict
Source Name Destination Name Notes
Provide a unique
identifier for every
object
Disallow anonymous
usage of the system
by using a single identifier for every device, there
will be no anonymous usage of the system
minimize

16. Tradeoff Analysis
Quality Features Relationships
S vs D FT IN QoS SY ST Total
AB 3 3
CS 2 2
FT 1 1 2
HD 1 1 2
SO 1 1 1 3
Total 4 1 1 4 2 12
minimize
S vs D EC HD PT QoS SY ST SO Total
AB 1 2 3
CS 1 1 1 3
EC 2 2
HD 1 1 1 3
IN 1 1
ST 2 1 3
SO 1 1 2 1 5
Total 4 1 5 2 5 2 1 20
maximize
S vs D AB FT HD PT QoS SY ST Total
CS 1 1
EC 1 1
HD 1 2 1 4
IN 1 1
ST 3 3
SO 1 1 2
Total 1 1 1 3 3 2 1 12
Conflict

17. Tradeoff Analysis
Complexity Weight
Feature # Requirements # Relations # Features score weight
SY 10 11 4 440 0.209524
ST 8 11 5 440 0.209524
SO 5 11 6 330 0.157143
ST 6 7 5 210 0.1
HD 3 11 4 132 0.062857
PT 4 8 4 128 0.060952
CS 5 6 4 120 0.057143
QoS 4 6 4 96 0.045714
AB 4 7 3 84 0.04
EC 3 7 4 84 0.04
IN 4 3 3 36 0.017143
Grand Total 56 88 46 2100 1

18. Tradeoff Analysis
Survey Order vs Complexity Order
Survey: The standard deviation (SD) of the difference of
ranking between the survey order and the complexity order,
as shown in Table 30, is 2.3741 which is relatively small. If we
divide the number of features by the SD, the result is 4.8,
which indicates that we can segment the ranking of the
features into 5 segments.
Feature Survey Order
(SUO)
Complexity order
(CXO)
Difference
CXO - SUO
FT 1 4 3
PT 2 6 4
ST 3 2 -1
SY 4 1 -3
SO 5 3 -2
QoS 6 8 2
CS 7 7 0
AB 8 9 1
HD 9 5 -4
IN 10 11 1
EC 11 10 -1

19. Tradeoff Analysis
Statistical Findings vs Subjective Findings
Key Comparison Our Research work Spínola and Travassos’s
research work
Service
omnipresence
Service omnipresent is ranked as one
of the top priority features
Service Omnipresence is a key
characteristic that is found in all
ubiquitous projects.
Classification of
the Business
Quality Features
We classified quality features as
enablers and constraint
Classified quality features as
functional and restrictive.
Enabler vs.
Functional
Categories
Enabler features are Adaptable
Behavior, Context Sensitivity,
Heterogeneity of Devices, and
Service Omnipresence
Functional characteristics are
context sensitivity, adaptable
behavior, service omnipresence,
heterogeneity of devices, and
experience capture.
Constraint vs.
Restrictive
Categories
Constraint features are Privacy and
Trust, Quality of Service, Safety,
Security, Fault Tolerance, and
Experience Capture
Restrictive characteristics are
privacy and trust, fault tolerance,
quality of service, and universal
usability.
Invisibility Quality
Feature
Invisibility cannot be classified as
enabler or constraint feature and it is
ranked as the lowest in priority
Invisibility was ranked the lowest
with respect to pertinence level.

20. Problem
There are 12 conflicts, which means that
6 requirements may be eliminated from
the scope of the business reference
architecture.

21. Conflict Resolution … Resolution Approach
Identify possible
conflicts
between pairs of
conflicts
Decide on which
requirement to
supersede
Propose
balanced
solutions
Revise Solution
vs
Requirement
Merge conflict
solutions if
possible
Group per
quality features
split by relations
Devise a
solution score
equation
Apply normality
test
Make subjective
evaluation with
experts

22. Conflict Resolution … Resolution Approach
Requirement
A
Requirement
B<<Conflict>>
+Superseding
<<Problem>>
Solution1 Solution2 Solutionn
Requirement
A
Requirement
B<<Conflict>>
+Superseding
<<Problem>>
Solution1 Solution2 Solutionn
Requirement
A
Requirement
B<<Conflict>>
+Superseding
<<Problem>>
RequirementA
supersedes
trace
(a)Selectoneofmany (b)Mergesolutions (c)Resolveforthesuperseding
requirement

23. Conflict Resolution (Example)bdd [Package] QF v s QF conflict #08 [QF v s QF conflict #8]
Ensure secure data
transmission
Derived
Security
(from Quality Features)
Minimize av erage
processing time
Derived
Quality of Service
(from Quality Features)
«solution»
Merged solution - conflict #8
+ Score = 1.2667
«solution»
architecture
Transfer non-securely if possible
+ Score = 0.4219
«solution»
architecture
Use light-w eight encryption algorithm
+ Score = 0.8200
«problem»
It is required to provide data protection during transmission which adds extra load on system
processing power. The extra load can drain batteries, slow down performance, and may impact system
overall availability. In other words, the average processing capabilities for the services may be negatively
impacted.
It is a controversial conflict, which can be resolved only during runtime based on the system priority,
data sensitivity, and user context.
However, as a general rule, lenient security rules may cause further deteriorations and the system may
be completely compromised
+Superseding
«conflict»

24. Solution vs Requirements (Example)
Use light-weight encryption algorithm
Relation Requirement
ID
Requirement
Name
Feature Notes
mi BR0047 Minimize the
probability of an
object to be offline
FT The light-weight encryption
algorithms have moderate impact
on processing power, which
minimizes a little bit the probability
of the object to be offline.
mx BR0059 Declare
service/quality
feature boundaries
QoS If impact of the light-weight
encryption is known to the system,
and accordingly it can declare the
expected response time
boundaries.
mi BR0060 Minimize average
processing time
QoS
mx BR0070 Provide maximum
protection for the
environment
SY This is a kind of protection for the
environment
mx BR0075 Ensure secure data
transmission
ST
mi BR0077 Prevent data
leakage
ST Encryption prevents data leakage
if network is compromised.

25. Conflict Resolution (Example)
Solution SO-017 (non securely) SO-018 (lightweight) SO-027 (merged)
Feature mi mx cf Total mi mx cf Total mi mx cf Total
SY 1 1 1 1 1 1
ST 1 1 1 3 1 1 2 2 1 3
SO 1 1 1 1
FT 1 1 1 1 1 1
HD
PT
CS
QoS 1 1 2 1 1 2 1 1 2
AB 2 2 2 2
EC
IN
Total 3 4 3 10 3 3 6 4 6 10
Score 0.4219 0.8200 1.2667

26. Conflict Resolution
𝑆𝑐𝑜𝑟𝑒 = 𝑅+ ∗ 𝐹𝑅 𝑤𝑒𝑖𝑔ℎ𝑡
+
− 𝑅− ∗ 𝐹𝑅 𝑤𝑒𝑖𝑔ℎ𝑡
− The formula estimates the positive impact of the
solution given the negative impact and as
expressed in formula (1).
R+ is the percentage of the minimize ( 𝑚𝑖𝑓
) and
maximize ( 𝑚𝑥𝑓
) relationships from all the
relationships of the solution with the other
requirements. R- is the percentage of the
conflict relationships ( 𝑐𝑓𝑓
) of the solution with the
other requirements.
𝐹𝑅 𝑤𝑒𝑖𝑔ℎ𝑡
+
=
𝑓=1
11
𝑚𝑥 𝑓 + 𝑚𝑖 𝑓 ∗ 𝑤𝑒𝑖𝑔ℎ𝑡 𝑓
𝐹𝑅 𝑤𝑒𝑖𝑔ℎ𝑡
−
=
𝑓=1
11
𝑐𝑓𝑓 ∗ 𝑤𝑒𝑖𝑔ℎ𝑡 𝑓
𝐹𝑅 𝑤𝑒𝑖𝑔ℎ𝑡
+
is the weighted average, an average
multiplied by its probability (Moore, et al., 2009),
of the minimize and maximize relationships of
the solution with the requirements belonging to a
single feature multiplied by the weight of this
feature (𝑤𝑒𝑖𝑔ℎ𝑡 𝑓) in Table 3. 𝐹𝑅 𝑤𝑒𝑖𝑔ℎ𝑡
−
is the
weighted average of the number of conflict
relationships of the solution with the
requirements belonging to a single feature
multiplied by the weight of the feature (𝑤𝑒𝑖𝑔ℎ𝑡 𝑓)

27. Solutions List
Sol ID Solution Sol ID Solution
SO-001 Associate device with user SO-002 Authenticate every time
SO-003 Delete unnecessary sensor data SO-004 Disable sensors if not needed
SO-005 Increase shared resources SO-006 Mediate access through a middleware
SO-007 Authorize access upon information request SO-008 Classify personal information as a setting
SO-009 Define information access explicitly SO-010
Teach the system (add to its knowledge
base)
SO-011
Declare security rules for the devices willing to
join the system SO-012 Scan devices before joining the system
SO-013
Apply less strict security rules on the private
smart environment SO-014
Apply less strict security rules on trusted
objects
SO-015 Log all changes for later access SO-016 Notify for important changes only
SO-017 Transfer non-securely if possible SO-018 Use a light-weight encryption algorithm
SO-019 Use compatible technologies SO-020 A positive merge of solutions (7, 8, 9)
SO-021 A positive merge of solutions (10, 19) SO-022 A positive merge of solutions (11, 12)
SO-023 A positive merge of solutions (13, 14) SO-024 A positive merge of solutions (15, 16)
SO-025 A positive merge of solutions (17, 18)

28. Conflict Resolution
Sol 𝐹𝑅 𝑤𝑒𝑖𝑔ℎ𝑡
+
𝐹𝑅 𝑤𝑒𝑖𝑔ℎ𝑡
−
R + R - 𝑆𝑐𝑜𝑟𝑒
SO-001 1.123 0 1 0 1.123
SO-002 1.058 0.280 0.545 0.455 0.450
SO-003 0.563 0.330 0.636 0.364 0.238
SO-004 0.178 0.347 0.429 0.571 -0.122
SO-005 0.730 0 1 0 0.730
SO-006 0.742 0 1 0 0.742
SO-007 1.415 0.146 0.833 0.167 1.155
SO-008 0.674 0.310 0.818 0.182 0.495
SO-009 0.830 0.034 0.778 0.222 0.638
SO-010 0.936 0 1 0 0.936
SO-011 0.949 0 1 0 0.949
SO-012 1.210 0.046 0.875 0.125 1.054
SO-013 0.355 0.419 0.600 0.400 0.046
SO-014 0.355 0.210 0.750 0.250 0.214
SO-015 0.204 0 1 0 0.204
SO-016 0.118 0.210 0.750 0.250 0.036
SO-017 0.802 0.465 0.700 0.300 0.422
SO-018 0.820 0 1 0 0.820
SO-019 0.582 0.157 0.800 0.200 0.434
SO-020 1.753 0.017 0.944 0.056 1.655
SO-021 0.936 0 1 0 0.936
SO-022 1.577 0.046 0.900 0.100 1.415
SO-023 0.355 0.419 0.600 0.400 0.046
SO-024 0.265 0.210 0.857 0.143 0.197
SO-025 1.267 0 1 0 1.267

29. 1.Our main contribution is the PervCompRA-SE
which captures all the essential business and
architectural knowledge in the PervComp
domain as diagrammatic models and
associated guidelines.
2.A new requirements engineering approach
that uses process re-engineering concepts.
3.An innovative statistical analysis methodology
to prioritize groups of requirements,
represented as quality features, and to
resolve conflicts among the requirements.
Conclusion
Contributions

30. 1. Design challenges in PervComp are very high
2. There are common and cooperating requirements
3. Trade-off analysis proved to be very useful
1. Requirements Relationships are indicative of their priority
2. Priority is not static
3. The Constraint Feature is just as important as the Enabler
Feature
4. Statistical Analysis can reduce the frequent engagement
of stakeholders
4. The invisibility quality feature is demolished
Conclusion
Findings

31. 1.Produce a product line architecture based
on the PervCompRA-SE
2.Evolve the study of requirements-conflict
resolution
3.Investigate the value of linking the
requirements with system performance at
runtime
Conclusion
Future Work

32. THANKS!
Any questions?
You can find me at
• okhaled@aucegypt.edu