Specifications

CHAPTER 3. REQUIREMENTS SPECIFICATION 20
3.3 Performance Requirements
As mentioned in the introduction of this chapter, the Input Abstraction Layer is an autonomous
background process which is always running. No matter whether there are any input events
to be processed or not, the daemon has always to be poised, to work them up as soon as they
occur. For this reason, it is essential that the Input Abstraction Layer does not consume more
system resources than needed—this applies to both processor usage and memory usage.
To reduce the consumption of system resources, user space applications should not need to
poll in order to access the Input Abstraction Layer’s output interface. An application using
the output interface should receive a signal from the Input Abstraction Layer once an input
event occurs. On the one hand, this ensures that input events arrive at user space applications
with the slightest possible delay. On the other hand, if applications do not need to poll, the
Input Abstraction Layer’s output interface induces less consumption of system resources.
For any user input, the peak response time is crucial. Normal keyboard input is acceptable
if the delay between keypress and response is within 25 milliseconds. The Input Abstraction
Layer has to meet requirements regarding response times as well. Depending on the input
interface, the peak response time varies since some of them need to be polled. In general, the
time between the user action and the arrival of the input event at the user space application
should not exceed a limit of 25 milliseconds. Since the Linux kernel does not meet real-time
requirements, the response time can not be guaranteed.
3.4 Quality Attributes
The Input Abstraction Layer has to fulfill the quality attributes which should be fulfilled by
all daemon processes. The daemon has to run stable and without interruption under normal
conditions. In case of a failure the daemon should handle the exception and issue an expressive
error message.
The configuration should b e carried out without much hassle. Critical parts should be
emphasized in the documentation. To address the many different system configurations the
Input Abstraction Layer should run on, the daemon has to be highly customizable to the
different needs.
The base configuration of the daemon should cover all available input interfaces. This
eliminates troubles for users with little experience. On start-up, the daemon has to identify
the available input interfaces and verify that it can access them accordingly.
To be prepared for future input interfaces, the daemon has to be easily expandable. This
also ensures that other developers are willing to enhance the Input Abstraction Layer by adding
support for not yet supported input interfaces.
3.5 Security Attributes
A sequence of several input events can contain sensitive data, e.g. passwords. On that score,
the Input Event Layer should report all but alpha numeric input events. Otherwise, a serious
security impact would be raised: since all user processes shall be able to receive input events
(fifth functional requirement, §3.2), a process could abuse the Input Abstraction Layer to
gather sensitive data.