This is a list of the basic requirements of many quality features that are considered essential in Pervasive Computing, Ubiquitous Computing, and Internet of Things. They can be applied to almost any distributed intelligent software system. Before you start developing your system, please consider these requirements in your scope.
For more comprehensive explanations about the quality features, requirements, and the trade-off analysis, please download the full research work from http://dar.aucegypt.edu/handle/10526/5053.
For citation:
O. M. Khaled, “Pervasive Computing Reference Architecture from a Software Engineering Perspective,” Ph.D. Thesis Dissertation, The American University in Cairo, Cairo, Egypt, 2017.
Beginners Guide to TikTok for Search - Rachel Pearson - We are Tilt __ Bright...
Basic requirements of Pervasive Systems, Internet of Things, and Ubiquitous Computing
1. Alias Name Note Quality Feature
1 Evaluate/Improve Adaptive actions
the system must review the adaptive actions continuously
and make the proper improvements to ensure they satisfy
the majority of the users Adaptable Behavior
2 Has smart decision rules
such decisions are dependent on the interpretations as
sensed from the environment. The decision rules must be
taken smartly in favor of a high priority goal maintained
by the system Adaptable Behavior
3 Notify users with changes
the user must be aware of the changes that the system
made through its adaptive actions. This will allow the
users to take counter measurements in case the system
took a wrong decision Adaptable Behavior
4 Possess actuation capabilities
these are the actuators that the system uses to respond
to the changes of the environment. These actuators can
be virtual or physical. Adaptable Behavior
5 Equip system with sensors
the sensors are essential for the system in order to collect
as much data as possible for analysis. Context Sensitivity
6 Locate interacting objects
at any point of time, the system should locate the objects
(smart or dummy). These objects could be interacting
with the system, or part of it Context Sensitivity
7 Provide analytical capability
the system is able to analyze the data collected by the
sensors and generate useful information and correct
errors if possible and if needed. Context Sensitivity
8 Provide interpretation rules
the system should be able to interpret information using
predefined interpretation rules Context Sensitivity
9 Record object lifetime
the system must register the lifetime trip of the objects
that are considered part of the system. Statistical records
should be available whenever needed. Context Sensitivity
10 Capture Knowledge about users
use the personal knowledge smartly to convey to the user
that the system is there and recognizes his/her work. For
example, capture the birth date, email, and sex, job type
so that you can tailor a better experience and
communication with the user on different occasions
Experience Capture
11 Correlate information and knowledge
Correlate information and knowledge to forecast events
and anticipate user or object behavior [40] Experience Capture
12 Capture/change behavioral patterns
the system should be able to capture pattern(s) that users
or objects repeat when they interact with the system [4].
The system should be able to change invalid patterns as
well if the user/object stopped them Experience Capture
13 Detect faults quickly the system must detect faults very quickly Fault Tolerance
14 Minimize Faults
the system must adapt all possible techniques that to
avoid or minimize faults. Fault Tolerance
15
Minimize the probability of an object to
be offline
the system must ensure the longest number of hours for
its object(s) in order to keep providing the automation
service for its interacting devices and users Fault Tolerance
2. 16 Reduce Error consequences
if an error occurred, then the system must reduce its
impact Fault Tolerance
17 Show proper error message
the system must show a friendly, descriptive, and
directive error message Fault Tolerance
18 Take the proper corrective action
the system must take the proper corrective action to
rectify the error and reduce its
impact. The corrective action could be
1. logging the error incident
2. Notifying concerned entities
3. Taking a counter action to fix the error or minimize
its impact Fault Tolerance
19
Maximize the number of device
technologies
allow different devices that use different technology to
join/leave the pervasive system with minimal human
involvement.
Hetrogeneity of
Devices
20
Provide a unique[1] identifier for every
object
every object should have a unique identifier that does not
conflict with other objects. For example, the system can
use a static IP address or a MAC address to identify
devices and facilitate communication with them.
Hetrogeneity of
Devices
21
Render content on maximum number
of devices
allow different devices to render the same content
according to their screen dimensions, network bandwidth
capacity, and processing capabilities. The content should
be visible, readable, and interactive.
Hetrogeneity of
Devices
22
Minimize unneeded interactions with
the system
The system must request minimal explicit input from the
users that interact with it Invisibility
23 Remove unnecessary motions
A pervasive system should reduce the time and effort
people usually do to complete their tasks. Accordingly,
unnecessary motions should be reduced to the degree
that makes the user tasks simple and intuitive Invisibility
24
Conceal the part object(s) of the
pervasive system
By concealing the system part object(s) in the smart
environment fabrications as much as possible Invisibility
25 Minimize the use of explicit input
the system should detect inputs implicitly and minimize
the use of traditional keyboard and pointing devices [41].
For example, the existence of a user in a certain location is
enough to get the user identity and get its exact address.
Invisibility
26 Certify trusted entities
entities that will manipulate information should be
certified. For example, a system may require registration
with details, then an admin reviews in order to grant the
right authority level. Privacy and Trust
27 Classify Information
the system must be able to differentiate among private,
social, and public information. Privacy and Trust
28 Reveal Information controllably
the system must reveal information to authorized entities
only based on its classification, and trust level of the
authorized entities. Privacy and Trust
29 Track Information
the system should trace private information to other
entities. Traceability may be used later on by the user that
owns this info if information is miss used Privacy and Trust
3. 30
Declare service/quality feature
boundaries
the system should specify its acceptable boundaries for
each quality feature or service by which the users can
acknowledge the failure of the service if the deadline is
breached. Quality of Service
31 Minimize average processing time The system should process tasks very quickly and on time. Quality of Service
32 Monitor and improve QoS boundaries
the system must continuously monitors its QoS for the
different services and work on improving them whenever
possible Quality of Service
33 Specify hard/soft deadline
The system must flag each response deadline for being a
hard or a soft deadline Quality of Service
34 Alert if safety is about/or compromised
the system should show proper alerts for the users if
safety is about/or compromised. These alerts should be in
multiple forms according. For example, alert could appear
on a screen, give high sound. Safety
35
Allow the user to override/cancel
system decisions
if the systems takes a wrong action that can cause
potential risk for users, then allow the user to override its
action or cancel it. Safety
36 Avoid conflicting side effects
the system must take proper actions that do not cause
side effects on people or devices which may reflect
wrongly on other devices and generate a chain of side
effects as well Safety
37 Avoid invalid operational directives
the system must provide safety limits for critical
operations in order not to cause damage based on wrong
user input Safety
38
Ensure that generated rules do not
conflict with system policy
the system may generate new rules driven from its
knowledge base. The new rules must not conflict with the
system policy that governs the usage of the system Safety
39
Minimize conflicting usage of shared
resources
the system must be able to resolve conflict over shared
hardware resources Safety
40 Override system rules by the regulator
the regulator should have the authority to override
system rules in critical situations in order to apply its rules
on all the society Safety
41
Provide maximum protection for the
environment
interacting users and machines should be protected from
injury and damage Safety
42
Resolve conflicts among objects by an
administrator
there should be a way that the administrator uses to
resolve conflicting situations among objects Safety
43 Respect society ethics the system must abide by the society ethical standards Safety
44 Disallow anonymous usage of system
the system must not allow anonymous usage of system
resources and services Security
45 Enforce Security rules over all objects
the system must ensure that security policy is applied
over devices that join the system and devices that fail to
fulfill the security requirements must disconnect
immediately. Rules are enforced as well over any activity
made by users. Security
46 Ensure secure data transmission
data transmission among devices must be secured and
protected against intruders [44]. Security
47 Maintain data integrity
the system must ensure corruption-free and alternation-
free data. Security
48 Prevent data leakage
provide maximum protection for data in order to avoid
leakage for unauthorized persons [44]. Security
4. 49 Provide data access rules
data should be accessed whenever wanted by different
entities, whether persons or machines, according to the
data security access rules. Security
50
Take counter-measures to mitigate
security threats
the system must take counter-measures to ensure that
risks generated from security threats do not cause any
harm for system users Security
51 Announce malfunctioning smart objects
The system must publish information about smart
object(s) that do not function or miss-behave in the
system. In other words, some objects may harm the
environment, and the community must be aware of such
objects in order to put them in the black list Security
52 Distribute computing power
if possible and if budget allows, then it is highly
recommended to distribute computing capabilities in the
environment where a pervasive system operates. This will
give an actual perception about service omnipresence Service Omnipresence
53
Enrich the experience of the highly used
scenarios
such scenarios must get the highest attention and
enrichment with the pervasive features (sensors,
awareness, actuators, intelligence) Service Omnipresence
54 Provide Informative messages
make sure to guide the user and build up his/her
experience through his/her interactions with the system.
For example, if it is the first time for the user to interact
with the system, then provide welcome messages, hints
and tips on how to proceed Service Omnipresence
55 Use a unique user identifier
a unique user identifier that can be used to access
different devices in the environment which can give the
user the feeling that the system knows him/her anywhere
and is ready to serve him/her at his/her convenience Service Omnipresence
56 Utilize the user mobile phone
users depend heavily on their mobile phones. Smart
phones are now considered a small computer with
multiple capabilities. Hence allow the user’s mobile phone
to be part of the system Service Omnipresence
57
Shared resource must keep acceptable
performance under increased clients'
requests
As the demand on shared sources increases, the system
should maintain an acceptable performance for all clients
in terms of connection time, processing time, and
response time [4] [31]. Concurrency
58
Shared resource must keep functioning
as designed under increased client
requests
The shared resource must provide the same designed
functions by the system regardless of the number of client
requests and regardless of the performance problems
that it may encounter [4] [31]. Concurrency
59
The published service should be
accessed via an authorization certificate
The published services may be used by service requesters
under some authorization conditions. These conditions
are satisfied via authorization certificates for the sake of
theenvironment’ssafety[52] or security. Accordingly,
there could be two major types of the certification 1)
public: where the service is accessed by anyone 2)
protected: where the access is granted to some people by
issuing a service provider certificate.
Openness
5. 60
The published services must have
documentation for developers
There must be documentation for every published service
that the integration developers can access and read [31].
Documentation may have a machine-readable format
version as well e.g. annotations [53]. Openness
61
The system should publish some/all its
services for external usage
As the openness concept implies, the system should make
as many as possible of its services available for other
systems or for developers. A system that does not publish
any service is a private system. A system that publishes
all its services is a public system [31].
Openness
62
The system should report about the
performance of its objects to interested
communities
The system should report to other interested
communities about the performance of the devices. For
example, the system may report about the response time
of a smart object in a context that has 1000 requests, 500
requests, or 100 requests. It can report on the same time
the memory size, network bandwidth, and CPU utilization
[5]. Openness
63
The system must be scalable within the
boundary of the available resources
Any system has a limited number of resources. These
resources set boundaries for the number of users that
they can serve. As the number of users increase towards
its maximum, the system should be able to satisfy their
needs with no problem [31]. Scalability
64
The system should add extra resources
transparently
The system should attach new resources to its structure
transparently with minimal interruption for the system
functions. These resources should start operating once
detected by the system. Scalability
65
The system should be able to forecast
the required resources
The system should build statistics that show the trend of
demand for its resources. These statistics give indication
for the system or the system administrator about its real
demand for resources according to different contexts. It
shows also an accurate number of needed resources
based on the increased requests from the users.
Scalability
66
The service communication protocol
must be light with respect to system
resources
The service offered by the system should provide a
suitable communication protocol that does not impact the
system’s overall performance and does not deplete
system energy quickly. Service Discovery
67
The service must declare its contract
interface
The service must declare its contract including its
parameters, expected output, and the communication
protocol. The service declaration should have enough
description for its contract. Service Discovery
68 The system must register new services
As new objects join the system, they may offer new
services. The system should be able to register the new
services and make them available for public, protect, or
private access accordingly to the system and the service
privacy policy. Service Discovery
69
The smart object should bind to the
system quickly
The smart object requesting a service from a system must
bind to the system very quickly. SIP
6. 70
The system should support smooth and
quick service handover
A smart object on the move and still wants to continue its
operations with specific services associated with the
system, should leave the service and bind to another
accessible one. This is called a handover process, which
should be smooth and quick. The system must release the
resources of the first service and allocate other resources
for the handed over service. Spontaneous
Interoperability
71
The system should support the
maximum number of communication
protocols
The system should consider the maximum number of
protocols that can be used among the different objects.
This will simplify the binding/association process and will
increase the spontaneous interoperability of the system.
Spontaneous
Interoperability
72
The system should use a standard
interoperable protocols
The system must not change its technical model
(information and architecture) dramatically to become
interoperable with other systems; instead, it should use
standardized protocols like ontology-driven
communication [54] or standard annotations [53]. Spontaneous
Interoperability
73
The system should be able to compose
new functions from simple or
composite functions
The system should link different functions or services
together to build new functions or services with new
results [50]. Composing Functions
74
The system should be able to compose
functions dynamically at runtime
Since the input and output of every function or service is
known at runtime, the system should be able to compose
new functions at runtime as well whether it is requested
by the user explicitly or required by the system to achieve
a specific goal implicitly [50]. Composing Functions
75
The system should satisfy the
requirements of the service requester
while composing new functions
The system should consider the functional and quality
requirements of the service requester. Quality
requirements such as cost, availability, latency, and
reliability are considered very important for an optimum
service composition [51]. Composing Functions