Specifications

Chapter 6

Requirements Veriﬁcation

This chapter compares the achieved goals with the requirements speciﬁcation deﬁned in Chap-

ter 3. First, the veriﬁcation of the functional requirements is performed. This part of the

veriﬁcation compares the implementation with the demanded functional requirements. Sec-

ondly, the performance requirements are veriﬁed. In order to verify whether the performance

requirements are met as demanded, a kernel driver was implemented to measure the latency

of input events. At last, the quality and security requirements are veriﬁed.

6.1 Functional Achievements

The ﬁrst functional requirement demands a utilized user space interface to report up to now

unattended input events. This requirement is fulﬁlled by the implementation of the Input

Abstraction Layer’s abstract output interface. This interface is shared by all modules to

report input events of the kernel drivers generating various input events.

The implemented output interface of the Input Abstraction Layer does not require any

privileges to be utilized by any user space application. This fact accomplishes the second

functional requirement which speciﬁes that the existing barriers have to be eliminated, with

one restriction: the Input Abstraction Layer itself has to run with root privileges, as some

kernel interfaces have access restrictions as deﬁned in Chapter 3, §3.1.

The uniﬁed data representation demanded by the third functional requirement is achieved

by the Input Abstraction Layer’s data structure IalEvent. It represents all kinds of input

events in a common way. The conversion of the concrete input events to the uniﬁed represen-

tation is performed by the Input Abstraction Layer’s modules.

The fourth functional requirement asks for a permanent location of the abstract output

interface. The location of the implemented output interface depends on D-BUS to a large

extent. If the application programming interface of D-BUS changes, it is unavoidable that the

Input Abstraction Layer’s output interface changes, too. Thus, this functional requirement is

only fulﬁlled as long as the Input Abstraction Layer does not change the name of the interface,

and the D-BUS’ application programming interface does not change.

The last functional requirement speciﬁes that the abstract output interface has to be in-

dependent in regards to the programming language of the application which wants to utilize

the interface. The requirement is entirely fulﬁlled since D-BUS oﬀers bindings for many recent

programming languages and frameworks, such as C, C++, Mono (e.g. C#), Qt (C++), Perl,

Python, Ruby and Java.