52 PART | II ITS users
Gahyyur, 2009). Although many of the earlier-mentioned elicitation techniques
can be useful for requirements elicitations for intelligent transport systems, but
they are not suitable because of the complexity involved in ITS.
4.4 Problems in ITS requirements elicitation
There are many issues that software and system designers face when they design
intelligent transport systems. The design of ITS is more than simply combining
telecommunication technology and information processing in novel transport
solutions. The involvement of different stakeholders, including end-users, ITS
managers, operators, and people that work on system maintenance increases the
system complexity and makes requirements’ elicitation harder. The ITS stake-
holders have:
• Diverse disciplines. The stakeholders come from different engineering do-
mains (e.g., transportation, mechanics, construction, etc.) that have varying
economic profiles and follow different public policies.
• Different types of businesses areas. Stakeholders comprise public agencies
such as governmental departments (e.g., department of transport) and en-
forcement agencies, and companies that manufacture ITS equipment or pro-
vide communication services.
• Mixed ownership and responsibilities that engage both public agencies and
private companies. An example is the management of the road network that
is the responsibility of the former, but is technically supported by the latter.
Designers must consider the multi-disciplinarity of the stakeholders, the dif-
ferent ways they work and their varying needs that drive the system objectives.
So, it is necessary for all collaborators to understand and accept these objec-
tives, and contribute to the elicitation of requirements, since the success of the
requirements elicitation task has an effect on user satisfaction. A successful ITS
design must address the values of all stakeholders and provide all the means for
collaboration and communication of all stakeholder teams during the require-
ments engineering process.
The details of the application domain, the overall system context, the com-
mon work practices, and the tasks that the system must perform constitute a
tacit knowledge that is difficult to be recorded and articulated with traditional
requirement elicitation techniques. In order to ensure system success, it is
necessary that the requirements elicitation process promote user collabora-
tion, and involvement in all phases (Bano & Zowghi, 2015). When this is
not achieved, requirements may be missed in this stage and identified in later
stages of system development, thus introducing further delays to the project
for code rewriting and validation. Apart from the desired system functional-
ity, requirements also cover user expectations about the system performance
as well as other qualitative attributes, which are defined as nonfunctional
requirements.