0% found this document useful (0 votes)
36 views15 pages

2016 Sluter

The document discusses requirements elicitation for geo-information solutions. It argues that geo-information solutions can achieve higher quality if developed with a user-centered design approach that defines user requirements. It presents a framework that can help experts design more efficient and satisfactory geo-information solutions by applying requirements engineering methods to understand user needs, tasks, and how geographic knowledge can support decision-making. While user-centered design is increasingly used, methodologies for eliciting requirements for geo-information solutions remain underdeveloped.

Uploaded by

Aline Borges
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
36 views15 pages

2016 Sluter

The document discusses requirements elicitation for geo-information solutions. It argues that geo-information solutions can achieve higher quality if developed with a user-centered design approach that defines user requirements. It presents a framework that can help experts design more efficient and satisfactory geo-information solutions by applying requirements engineering methods to understand user needs, tasks, and how geographic knowledge can support decision-making. While user-centered design is increasingly used, methodologies for eliciting requirements for geo-information solutions remain underdeveloped.

Uploaded by

Aline Borges
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

The Cartographic Journal

The World of Mapping

ISSN: 0008-7041 (Print) 1743-2774 (Online) Journal homepage: http://www.tandfonline.com/loi/ycaj20

Requirements Elicitation for Geo-information


Solutions

Claudia Robbi Sluter, Corné P. J. M. van Elzakker & Ivana Ivánová

To cite this article: Claudia Robbi Sluter, Corné P. J. M. van Elzakker & Ivana Ivánová (2017)
Requirements Elicitation for Geo-information Solutions, The Cartographic Journal, 54:1, 77-90,
DOI: 10.1179/1743277414Y.0000000092

To link to this article: http://dx.doi.org/10.1179/1743277414Y.0000000092

Published online: 20 Jun 2016.

Submit your article to this journal

Article views: 99

View related articles

View Crossmark data

Full Terms & Conditions of access and use can be found at


http://www.tandfonline.com/action/journalInformation?journalCode=ycaj20

Download by: [CAPES] Date: 04 October 2017, At: 10:28


The Cartographic Journal Vol. 54 No. 1 pp. 77–90 February 2017
© The British Cartographic Society 2016

REFEREED PAPER

Requirements Elicitation for Geo-information Solutions


Claudia Robbi Sluter1,2, Corné P. J. M. van Elzakker3 and Ivana Ivánová4
1
Pós-graduação em Ciências Geodésicas, Departamento de Geomática, Universidade Federal do Paraná, Centro
Politécnico, Jardim das Américas, Caixa Postal 19001, CEP 81531-980, Curitiba, Brazil. 2CAPES – Coordenação de
Aperfeiçoamento de Pessoal de Ensino Superior, Setor Bancário Norte, Quadra 2, Bloco L, Lote 06, CEP 70040-020 -
Brası́lia, DF, Brazil. 3Department of Geo-Information Processing (GIP), Faculty of Geo-Information Science and
Earth Observation (ITC), University of Twente, PO Box 217, 7500 AE Enschede, The Netherlands. 4Departamento
de Cartografia, Faculdade de Ciência e Tecnologia (FCT), Universidade Estadual Paulista (UNESP), Rua Roberto
Simonsen 305, CEP 19060-900, Presidente Prudente, Brazil
Email: robbi@ufpr.br
Downloaded by [CAPES] at 10:28 04 October 2017

Geo-information solutions can achieve a higher level of quality if they are developed in accordance with a user-centred
design that requires definition of the user requirements in the first step of solution construction. We treat a geo-
information solution as a system designed to support human-based activities in a specific context through which solutions
to contextual problems can be achieved via geographic knowledge. Geographic knowledge is a result of geo-data
exploration, analysis, interpretation and dissemination with a given geo-information system. Taking the characteristics of
geo-information systems into account, existing methods and techniques of requirements engineering may be applied for the
design and implementation of geo-information solutions. Based on these considerations, here we present a generic
framework that can aid geo-information experts, geo-informaticians and cartographers in the design and construction of
more efficient, effective and satisfactory solutions.

Keywords: user requirements, geoinformation solution, requirements elicitation, requirements engineering

INTRODUCTION domain was noted by Lloyd (2009), who concluded that this
area is still under-investigated.
This paper presents a discussion on adjusting and applying
A framework for eliciting requirements is the first task in
known methods and techniques of requirements elicitation to
the design of geo-information solutions. Higher quality establishing a methodology for developing geo-information
solutions are achieved via user-centred design, which requires solutions as a result of requirements engineering.
that the user requirements are defined in the first stage of the Requirements engineering evolved from the software
work and that every decision in the design process is based on engineering discipline due to the need to improve software
those requirements. The user requirements determine the quality and to minimize the occurrence of programming
type of solution, e.g. a simple map, a set of maps, an interactive errors. Problems related to high costs, missed schedules,
map, a geographical information system (GIS), a geo- unsatisfied users and unexpected difficulties in system
visualization system or a virtual reality solution. maintenance were the result of an ineffective approach to
Currently, although user-centred design is increasingly requirements definition (Ross and Schoman Jr, 1977). The
promoted in the geo-information domain (Wealands et al., relevance of defining the requirements for computer
2005; Lloyd, 2009; Yovcheva et al., 2010; Tsou, 2011), a systems stimulated its evolution over the last four decades
sound methodology for requirements elicitation and analysis (Kotonya and Sommerville, 1998).
is still half developed at best. Few scientific papers exist that The elicitation of user needs requires not only knowledge
describe research results in which the goal is related to of the users and their problems that call for solutions but
requirements definition for geo-information applications. In also an understanding of their skills and expertise as well as
one example, Nelson et al. (2007) described an approach to the decisions that they have to make. If geographical
requirements description based on informal problem analysis knowledge is a requirement for carrying out selected tasks
applied to a geographic application. The need for research on related to user responsibilities, the users need a type of geo-
requirements elicitation and analysis for the geo-information information solution for decision-making or knowledge

DOI: 10.1179/1743277414Y.0000000092
78 The Cartographic Journal

insights. Therefore, the designer of a geo-information


solution must understand the relationship between the
users’ responsibilities and the users’ tasks.
One of the challenges in defining the requirements for
geo-information solutions involves gaining an understand-
ing of the specific character of geo-information and its
influence on the design of solutions that match the users’
goals and needs. Therefore, expert knowledge (e.g.
cartography and geo-information science) is necessary for
building a usable geo-information solution. The cartogra-
phers and geo-informaticians must be able to analyse the
user requests and decide what is possible to build and at
what cost.
The user requests should be defined in accordance with
the methods and techniques of requirements engineering
for computer systems. The similarities between user
requirements for geo-information solutions and require- Figure 1. Characteristics of geospatial data. Source: Adapted from
ments engineering theory lead us to our main objective, i.e. Kraak and Ormeling (2010)
to investigate whether the known methods and techniques
of requirements elicitation can be applied in the geo- groups: geo-information, geo-visualization and geo-data-
information domain, taking into consideration that a geo- base. The geo-information components are location,
information solution is a system-based product that is the attribute and time. Every geo-information system is based
Downloaded by [CAPES] at 10:28 04 October 2017

result of an engineering process. Consequently, the on representation of geographic location (Virrantaus et al.,
possibility of relating requirements engineering and geo- 2009), and the geo-information characteristics are estab-
information solutions requires that the latter are defined as lished (Figure 1) together with the attributes and time
a system. In our research, a geo-information software (Kraak and Ormeling, 2010). The geo-visualization com-
system can range from a simple static map to a complex ponents allow us to view the results of geo-processing and
geo-visual analytics system, and we assume that a basic set of to develop visual analysis. These components are display
components always exists as a portion of every geo- medium, spatial resolution, symbology and interactive cap-
information system. The set of components, their char- abilities. The geo-database components are related to the
acteristics and their relationships can differ due to different tasks of storing, modelling, managing and accessing spatial
use contexts and user needs. data. The set of components of this proposed framework is
This paper is organized as follows. First, we define a geo- a generic one because it forms a framework for any geo-
information solution as a system and subsequently describe information software system. Each of these components is
our understanding of the techniques and methods of composed of a set of sub-components that defines a geo-
requirements engineering in a geo-information context. information software system at a more detailed level of
Finally, we describe how requirements elicitation techni- functionality, and their characteristics are established in
ques and methods should be applied in the geo-domain to accordance with the user requirements (Figure 2).
make decisions on a geo-information solution design based The display medium is one of the basic components of
on user requirements. the system because the computer screen presents the geo-
information. The display medium determines the size,
colour resolution and image resolution of the graphical
solutions. The video size presents a constraint for the
THE GEO-INFORMATION SOLUTION AS A SYSTEM
decision on the screen map scale, which will set the
According to NASA (2007, p.3), ‘systems engineering is a conditions for a multiple-scale solution. For example, it is
methodical, disciplined approach for the design, realisation, possible to represent the same geographic region on a 200
technical management, operations, and retirement of a screen at a larger map scale than on a 150 screen, thus
system. A ‘‘system’’ is a construct or collection of different allowing the user to view more detailed information on a
elements that together produce results not obtainable by the larger screen. Although this scenario is obvious to
elements alone’. The value of the system is determined by the cartographers or geo-informaticians, if the level of detail
interactions of the system’s different elements (NASA, of the screen maps demanded by the user matches a 150
2007). From the engineering point of view, a geo-informa- screen solution, the screen size must be a component of the
tion solution can be designed and built as a system intended system requirements. More complex situations occur in case
to represent and disseminate geo-information. of small screens (e.g. smartphones), which require a
An assumption in our proposition is that a set of basic definition of the minimum level of generalization for the
components exists for any type of geo-information system, maps on the screen.
and the specifics of the different solutions are established as The minimum level of generalization defines the spatial
a result of the geo-information system design. The design resolution that must be modelled and stored in the geo-
of the solution must be based on the requirements database. In addition to the display medium, the minimum
specifications, which include the user requirements and level of generalization is also defined in accordance with the
needs. The system components are organized into three necessary geo-data processing and analysis requirements of
Requirements Elicitation for Geo-information Solutions 79

Figure 2. Basic set of components of geo-information systems and their relationships


Downloaded by [CAPES] at 10:28 04 October 2017

the users. For instance, if it is only possible to store and because the legend design must be based on certain specific
consequently depict urban areas and main roads at a certain elements, i.e. layout and position, here it is understood as
level of generalization, the user cannot acquire knowledge one different component of symbology. The size of the
of the spatial distribution of buildings and other auxiliary display can make the legend design rather difficult with
roads. If this second level of geographic knowledge is respect to legend position and layout (Figure 3).
required, the system should be designed accordingly. In this The interactive capabilities are defined in accordance with
work, the user requirements for spatial analysis impose the the level of user interaction demanded by the user
level of generalization of geo-information that can be stored requirements. Therefore, this item depends on display
and displayed, and this requirement is one important medium and determines certain characteristics of the
condition for the decisions on the hardware and the symbology and the related legend (Figure 3). At this stage
software in the geo-information system design (Figure 3). in our research, we assume that the display medium is always
The display medium also constrains the characteristics of a computer screen and that the type of interaction is
the symbology (level of detail, colour and size of the accomplished in a non-immersive environment using a
cartographic symbols). The legend is another important mouse or touch screen. These maps can be dynamic and are
geo-visualization element (Dykes and Wood, 2010), and designed and implemented as single-user environments

Figure 3. Component relationships that are application dependent


80 The Cartographic Journal

Figure 4. Sub-components of symbology for a 2D map solution

(Haklay and Chao Li, 2010) or web-mapping applications server. These two types of database implementation require
(Kraak and Brown, 2001; Skarlatidou, 2010). From the different database designs, and, consequently, different
Downloaded by [CAPES] at 10:28 04 October 2017

point of view of design of a geo-information software system solutions for storage, maintenance and implementation of
based on user requirements, the differences between these the geo-data structures. Modelling, storage, processing, and
choices rely on the interactive tools for handling geo-data. In semantics are four possible aspects of geographic information
a single-user environment solution, the interactive capabil- (Virrantaus et al., 2009), and the cartographer or geo-
ities depend on the software implementation that runs in a informatician must be prepared to use all of this knowledge
stand-alone solution. For web-mapping applications, the to propose a suitable solution for the users of a geo-
software implementation is based on web services for spatial information software system.
data (Tsou and Curran, 2008). Today, the Open Geospatial In addition to identifying and defining the system
Consortium standards (OGC, 2013) are widely used for components, the designer of a geo-information system
Web Map Services, and the Geography Markup Language must take into consideration their relationships, which are
makes web mapping applications possible for either desktop established in accordance with the purpose of representing
browsers or mobile platforms (Köbben, 2007). and disseminating geo-information. The quality of the
Any geo-information software system requires representation solution is measured in accordance with the user require-
of the geo-data in a geo-database (Burrough and McDonnell, ments (Chrisman, 1984). Therefore, the system’s effective-
1998; Kraak and Ormeling, 2010). A geo-information solution ness, efficiency and user satisfaction should be the objective
can be simply designed as a system based on only a PC and of the geo-information solution instead of the technological
stand-alone database software or as a database that runs on a sophistication of the system’s components.

Figure 5. Sub-components of symbology for a 3D map solution


Requirements Elicitation for Geo-information Solutions 81
Downloaded by [CAPES] at 10:28 04 October 2017

Figure 6. An illustration of geo-information system components. The basic set of components is represented inside the ellipse

Selected examples of the relationships between the characteristics of any solution component and the compo-
system’s components are illustrated in Figure 3. The basic nent relationships.
set of components of geo-information systems shows that
geo-information location, attribute and time define the
spatial data content that is to be modelled, structured and
UNDERSTANDING REQUIREMENTS ENGINEERING
managed in the geo-database. Location accuracy and spatial
METHODS AND TECHNIQUES
resolution are directly dependent on each other. If we can
define the data accuracy from the user requirements, then Due to the large number of possibilities for geo-informa-
we can also establish the minimum level of generalization tion solutions, we propose a theoretical framework for the
for the spatial data content. The minimum level of design of any type of geo-information solution in the
generalization defines the largest possible scale for the defined problem domain. In requirements engineering,
maps built from those geo-data. The options for accessing the problem domain is defined in accordance with
the data in the geo-database (data accessibility) determine stakeholders’ needs and demands. A stakeholder is any person
the possibilities of the map and software interactions or any entity that has an interest in the system (Kotonya and
(interactive capabilities), whereas the user needs define Sommerville, 1998; Cockburn, 2001; Hull et al., 2005), and
the interactive tools that must be implemented in the the users are those stakeholders that will directly interact with
system interface. Attributes and time, together with spatial the system (IEEE, 1998; Sutcliffe, 2002). According to the
resolution, influence the decisions in creating the graphical definition of a system adopted in this research (NASA, 2007,
elements of a map symbology. For a solution based on 2D p.3) and adapted to the geo-information context, the
maps (static screen maps), the symbology component has a components of a geo-information software system could be
different set of sub-components (Figure 4) than a solution people, hardware, software, facilities, policies, documents and
that requires 3D maps (Figure 5). In a 3D graphic the necessary geo-data. Figure 6 illustrates that if people,
representation, the shading pattern of a scene is dependent hardware, software and certain equipment are defined as
on the illumination model, which is defined in accordance system components, then they are an element of the system
with the characteristics of the surface and the position and domain, and their relationship to the system basic components
characteristics of the light source (Foley et al., 1990). must be defined.
In conclusion, the system requirements specifications A geo-information software system may be required if
define the design of the solution and, therefore, of the users must make decisions based on geographic knowledge.
82 The Cartographic Journal
Downloaded by [CAPES] at 10:28 04 October 2017

Figure 7. System development process and traceability. Source: Adapted from Hull et al. (2005)

Figure 8. Adaptation of the ‘four worlds’ model to a geo-information system. Source: Adapted from Sutcliffe (2002)
Requirements Elicitation for Geo-information Solutions 83

Figure 9. Activity model of the requirements engineering process adapted to a geo-information solution. Source: Adapted from Kotonya and
Sommerville (1998)

Therefore, a geo-information software system can be To achieve the best levels of efficiency, effectiveness and
understood as a special type of bespoke system (Kotonya user satisfaction, a geo-information system based on
and Sommerville, 1998), and consequently, it can be requirements engineering must be developed in a set of
Downloaded by [CAPES] at 10:28 04 October 2017

designed and built in accordance with user requirements stages. Because the requirements for the geo-information
defined by requirements engineering methods and techni- system are fulfilled only if they are considered in every stage
ques. The use context can consist of any set of individual of the product design and implementation, every decision
citizens or organization activities that require a geo- in the process must be based on the established user
information solution. For example, the organization could requirements. The relationship between the system require-
be public or private, governmental or non-governmental, a ments and every stage of the development of a geo-
small or large enterprise, and so on, and the organizational information system can be understood and organized as the
purpose could be business or scientific research four worlds model (Sutcliffe, 2002). In this research, we
development. assume that the adaptation of the four worlds model to a
The development of software solutions via an engineer- geo-information system (Figure 8) is suitable for any type of
ing approach has stimulated the proposal and improvement geo-information solution. The usage world is defined in
of models for design and implementation of computer accordance with the users and their need for geo-informa-
systems. Since the proposal of the ‘waterfall model’ (Royce, tion. The usage world is transformed into the geo-information
1970), software engineering models have been defined solution design world, which is transformed into the geo-
based on the assumption that the complexities of the system information solution production world, and the result is the
domain and user needs (problem domain) are treated at geo-information solution world. Each one of those worlds is
different levels of abstraction. The software implemented in defined by proper theory and methods. The ‘worlds’ are
the computer (machine) is accomplished at the lowest level connected to each other by information flow, which carries
of abstraction, and the requirements definitions at the the results of every stage of building geo-information
highest level because they are closer to our (human) view of solutions from one ‘world’ to another. In this manner, the
the world (Ross and Schoman Jr, 1977). The different results achieved in the user requirements elicitation stage
levels of abstraction are represented by different models, i.e. form the basis for the geo-information design tasks.
requirements, analysis, design and implementation, and Similarly, the production tasks are defined and accomplished
these models require methods that make possible the in accordance with the geo-information design results. Once
mapping of one model to another (Nosek and Schwartz, again, the performance of the geo-information solution
1988). In this process, the outputs from one model act as depends on the user requirements definitions.
the inputs for the next level of abstraction model. For In the four worlds view model, the usage world represents
instance, the outputs from requirements specification are the application domain, which is also referred to as the use
the inputs for the analysis model. In requirements context (Sutcliffe, 2002). The application domain defines
engineering, the transformation of high-level to low-level the purpose of the geo-information system and sets the
requirements is known as traceability. Every model at a system boundaries. Therefore, the definition of the geo-
different level of abstraction (Figure 7) should be defined in information system domain should be the first task in
accordance with a set of requirements. Because the entire developing a solution. The geo-information use context is
process of system development is dependent on require- established in accordance with the goals and requirements
ments, it is important to understand that requirements exist of the stakeholders. The intended goals and the expected
at each level of abstraction, i.e. statements of needs, results and requirements are the system characteristics and
stakeholder requirements, system requirements and system capabilities that make it possible to achieve those results
component requirements. For large systems, subsystem (Fairly, 1985). The usability of the final solution is verified
component requirements also exist (Hull et al., 2005). only for the defined use context specified by the system
84 The Cartographic Journal

Figure 10. Adaptation of the generic requirements elicitation process to a geo-information software system. Source: Adapted from Kotonya
and Sommerville (1998)
Downloaded by [CAPES] at 10:28 04 October 2017

domain. The description of the geo-information use must be discovered at the beginning of the solution design
domain is the result of a requirements elicitation process (Figure 9). During requirements elicitation, the task of the
as defined by Kotonya and Sommerville (1998). requirements engineers is to gather information useful in
The final product of requirements engineering is system understanding the characteristics of the problem domain as
specification, which forms the basis of the design and well as the stakeholders’ requirements (Kotonya and
implementation processes. The specifications of a system can Sommerville, 1998; Bray, 2002).
be accomplished in four different activities: elicitation, analysis, The requirements elicitation process is accomplished using
documentation and validation (Figure 9). At the end of the four different tasks: establish objectives, understand back-
validation stage, the requirements are considered correct, ground, organize knowledge and collect requirements
detailed, unambiguous and sufficiently complete to match the (Figure 10). The elicitation process begins with establishing
needs and requirements of the stakeholders, including the the objectives and defining the problem to be solved by the
system’s users (Kotonya and Sommerville, 1998). geo-information solution. Cartographers or geo-informaticians
As noted by Nosek and Schwartz (1988, p.1372), at the must understand the relationship between user activities and
requirements validation stage, it is important that the users the problems these activities aim to solve. For a geo-
check ‘whether the problem statement has been transformed information software system, the process of proposing a
accurately into the requirements document’. In the require- solution for the problem must be accomplished based on
ments validation step, any errors or mistakes made during the geographic knowledge and the consequent geo-information
requirements engineering process must be detected and analysis. The expected results of geo-information analysis are
corrected. The process of preparing and validating the agreed achieved if the necessary conditions and constraints for the geo-
requirements document is iterative because it is based on information software system are defined. As an example,
negotiation between stakeholders and requirements engi- suppose that users must carry out exploratory analysis and that
neers. The agreed-upon requirements document (Figure 9) they wish to use an interactive solution in a single-user
means that the negotiation between stakeholders (including environment only. In such a case, certain possible conditions
the users) and requirements engineers reaches a solution that for the system design are that the necessary data must be stored
satisfies the stakeholders and that this solution can be in the user’s workstation, the maps must be depicted on the
implemented. The design of the solution must result in computer screen and the interactive tools must enable the
system behaviour that meets the specified requirements achievement of the defined goals. These conditions require the
(Kotonya and Sommerville, 1998; Bray, 2002). specification of the characteristics of the computer (e.g.
memory, capacity), the geo-database software and the compu-
ter screen size and resolution. More specifically, the computer
memory and geo-database software must reflect the character-
FRAMEWORK FOR REQUIREMENTS ELICITATION istics and amount of necessary data, including geo-data. The
APPLIED TO GEO-INFORMATION SOLUTIONS computer screen size and resolution and the characteristics of
the video card must be suitable for graphic map solutions and
interaction tools to stimulate insights in the exploratory analysis
Stages in the requirements elicitation process stage, which is a constraint for the map scales.
Elicitation is the first activity in describing the requirements for After performing the first task in requirements elicitation,
a geo-information software system because the requirements the cartographer or geo-informatician must study and
Requirements Elicitation for Geo-information Solutions 85

understand the knowledge background (at a suitable level) organized according to the main steps of the requirements
with which the users will develop certain tasks that demand elicitation process:
geographic knowledge. The usual techniques applied in this
stage of the work are document analysis and interviews. N User activity:
Examples of user activities include tasks as specific as the 3 What is the overall activity that the users must
development of a Municipal Master Plan (MMP), monitor- execute in the business or research organization of
ing and improvement of a public health system, and the users or during personal decision-making (e.g. a
management of sylviculture for the paper and cellulose car route for a tourist trip)?
industry. User requirements can also be related to personal 3 What is the knowledge background of the user
decision-making, e.g. renting a house or using Google activity (e.g. urban planning for the development of a
Maps for planning car routes for a family holiday. At this master plan, forest and agriculture engineering and
stage of the requirements elicitation process, the goal is to economics for environmental protection or transpor-
understand the system background based on knowledge of tation, traffic engineering and urban planning for
the use context characteristics, the application domain and public transportation in urban areas)?
the existing geo-information solutions. In software engi- 3 What are the mission, goals and objectives of the user
neering, for the case in which the new system is an upgrade activity (e.g. job, scientific research, tourism)?
of a previous system, it is necessary to have knowledge of
the existing system. For production of a geo-information
software system, it is necessary to understand the previous
N Problem to be solved:

solutions for geographic analysis that are adopted by those 3 What problem is to be solved?
who use the geo-information. The understanding of an 3 What required geographic knowledge is related to
application domain and how to define it is well known in the problem?
Downloaded by [CAPES] at 10:28 04 October 2017

the geo-information field. Every thematic map is built with


data collected from an application domain. The use context N Geo-information solution constraints:
that must be understood is the one in which the user
3 What are the geo-data conditions that are required to
activities are performed.
solve the problem?
The third stage of requirements elicitation involves
3 What are the constraints for the geo-data and the
organization of the knowledge acquired from the two
geo-information system that are required by those
previous tasks. The knowledge that must be organized
conditions?
refers to stakeholder identification and characteristics,
priority ranking of the goals of the user activities and
essential and important knowledge of the application N Objectives of the geo-information system:
domain. From the use context characteristics, information 3 Based on the activity goals, the problem to be solved
is available that allows identification of the stakeholders, and and the solution conditions and constraints, what are
from the stakeholder responsibilities in the application the objectives of the geo-information system?
domain it is possible to describe their characteristics. The
knowledge, professional background and experience of the N Application domain:
geo-information users have a strong influence on their 3 What is the administrative and/or professional
spatial cognition and consequently on their view of the organization for the user activity?
spatial feature characteristics and relationships. For the same 3 How is this organization related to the activity’s
geographic region and spatial phenomenon, users with goals and objectives?
different backgrounds (i.e. urban planners, transportation 3 Based on the objectives of the geo-information
engineers, physicians or tourists) will seek different answers software system, what is the definition of the
because they understand the spatial phenomenon relation- application domain of the geo-information system?
ships in different ways. Consequently, the geo-information
solutions must contain various characteristics to be useful to
different users. N If a geo-information solution is already in use:
The result of the third stage is the knowledge that forms 3 What aspects of the problem can this system still
the basis for defining the requirements and the decisions on solve and how?
the geo-information software system design and implemen- 3 Which activities cannot be solved and what are the
tation. Knowing the use context characteristics and the reasons?
application domain makes it possible for the cartographer or 3 Is it efficient (cost/benefits rate) to use a component
geo-informatician to understand and define the system of the old geo-information solution?
requirements, which are a collection of requirements from
the stakeholders, the application domain and the use context. N Stakeholder and user identification:
3 Who are the stakeholders in the application domain?
Proposed guideline for eliciting requirements for a geo-information 3 What characteristics of the stakeholders must be taken
software system into account in the geo-information system design?
To guide the requirements elicitation process, we present 3 What are the relationships among the stakeholders,
the following set of questions, proposed in accordance with the application domain and the geo-information
the process illustrated in Figure 10. These questions are system?
86 The Cartographic Journal

3 Among the stakeholders, who are the geo-informa- geo-informaticians if their aim is to investigate the usability
tion system users? of interactive maps or geo-visualization systems. Those
3 What are the users’ responsibilities and tasks in their techniques, e.g. document analysis, interviews and ques-
activity context? tionnaires, can also be used to carry out the requirements
elicitation process for a geo-information software system
N Goal prioritization and domain knowledge filtering: and answer the questions listed in our proposed guideline
above as follows:
3 How do the users tasks fit into the activity’s goals and
objectives? N Document analysis (Suchan and Brewer, 2000) at the
3 What geographic knowledge do the users need to beginning of the requirements elicitation process for
build up? learning related to:
3 How is the geographic knowledge applied by the
users to accomplish their tasks? 2 The activity’s expertise;
3 How do the users make decisions based on geo- 2 The activity’s mission, goals and objectives;
graphic knowledge?
3 Based on the activity’s mission and goals, the N Document analysis and literature review for acquiring
application domain, the problem to be solved and knowledge of:
the stakeholders’ demands, what are the criteria used 2 The activity context (business or research organiza-
to define the priorities for the geo-information tion or personal decision-making) expertise;
system goals, and consequently, the ranking of these 2 The relationship between the administrative and/or
goals? professional organization;
3 According to the geo-information system goals, what 2 The activity goals and objectives;
Downloaded by [CAPES] at 10:28 04 October 2017

knowledge of the application domain will act as the


basis for the design of the geo-information software
system? N Interviews (Suchan and Brewer, 2000; van Elzakker,
2004) for:
N Collect requirements: 2 Refining the definition of the activity context
(business or research organization or personal
3 What are the stakeholders’ (including the users)
decision-making) mission, goals and objectives;
requirements for the geo-information software system?
3 What are the application domain and the organiza- 2 Improving the knowledge of the activity context (business
tion requirements for the geo-information software or research organization or personal decision-making)
system? expertise;
The result of the requirements elicitation task is a ‘first
requirements’ document. This document is used as the
N Brainstorming (Parnes and Meadow, 1959; Collaros and
Anderson, 1969; Bouchard Jr, 1972) for understanding
input for the requirements analysis task. According to the the initial concepts of the problem to be solved by the
Revision of IEEE Std 830 – 1998: Recommended Practice geo-information software system;
for Software Requirements Specification (IEEE, 2009), the
requirements document should address selected basic issues
N Unstructured interviews (van Elzakker, 2004) for defin-
ing the problem and the geographic knowledge related
in this research that are adapted to geo-information to the problem;
software systems according to the following: N Questionnaires (Suchan and Brewer, 2000) and interviews
N Functionality – What is the geo-information software (Suchan and Brewer, 2000; van Elzakker, 2004) for:
system intended to do?
N External interfaces – How does the geo-information 2 Refining the problem;
2 Defining the geo-information solution conditions
system interact with people, with the system’s hardware,
with other hardware and with other software? and constraints required by the characteristics of the
N Performance – What is the speed, availability, response problem and geo-information analysis that will be
used in the solution of the problem;
time, recovery time, etc. of the various geo-information
software system functions?
N Attributes – What are the requirements of the system’s N Interviews and task observation (Suchan and Brewer,
portability, correctness, maintainability, security, etc.? 2000) for understanding the previous geo-information
N Design constraints imposed on an implementation – Are solutions;
there any required standards in implementation lan-
guage, policies for geo-database integrity, resource
N Document analysis, interviews and questionnaires
(Suchan and Brewer, 2000) for understanding the
limits, operating environment(s) etc.? application domain and the organization structure;
N Interviews, task observation and questionnaires (Suchan
and Brewer, 2000) for identifying stakeholders and
Selected techniques for eliciting requirements for a geo-information system users and understanding their characteristics;
software system N Questionnaires (Suchan and Brewer, 2000) for defining
Most of the techniques described in the literature on the priority ranking for the activity context (business or
requirements engineering are used by cartographers or research organization or personal decision-making) and
Requirements Elicitation for Geo-information Solutions 87

goals and essential and important knowledge of the implementing an MMP: state and municipality government
application domain; technicians and consultants. In this example, the users of
N Questionnaires and interviews (Suchan and Brewer, the geo-information system are the state government
technicians who work for an institution known as
2000) for defining the user tasks related to the problem
domain and how the geographic knowledge is used; Paranacidade ,http://www.paranacidade.org.br/..
N Task scenarios and focus groups (Suchan and Brewer, Paranacidade is responsible for promoting and delivering
the activities and services related to regional, urban and
2000; van Elzakker, 2004) for:
institutional development of the State of Paraná munici-
2 Understanding how the users make decisions based palities as well as management of public financial resources.
on geographic knowledge; The responsibilities of Paranacidade relative to the MMP
2 Defining the components and their relationships in are (Paranacidade, 2010):
the proposed geo-information system;
2 Defining the requirements for the system function-
N To aid the municipality administration in organizing a
team of technicians responsible for monitoring and
ality, external interfaces, performance and attributes. evaluating every step of the development of the MMP;
The final product of the requirement definition process is N To plan and organize actions that enable knowledge
the agreed requirements document (Figure 9) (Kotonya exchange between municipality technicians and consultants;
and Sommerville, 1998). The defined requirements can be N To solve the doubts of the consultants or municipality
divided into two groups: stakeholder requirements and technicians relative to the development of the MMP
system requirements. The first category is represented by a goals, methodology or activities schedule;
use model, and the latter category is represented by a N To guarantee that the MMP is in accordance with the
conceptual (e.g. object-oriented analysis) model of a system federal, state and municipal laws, especially with Federal
Downloaded by [CAPES] at 10:28 04 October 2017

(Coad and Yourdon, 1990; Booch, 1994). One successful Law nu 10.257 (BRASIL, 2001);
proposed model for use-model representation is the use- N To establish guidelines for implementation of a perma-
case model (Bittner and Spence, 2003). A use-case model nent and sustainable municipal planning process that will
represents the interactions between the users and the system be used by the municipality technicians.
in a diagrammatic manner and from an external point of Paranacidade is organized as a directorate, and every
view (Jacobson, 1992; 1994). The representation of the directorate has offices. The geo-information solution stake-
system’s functionality as a result of the interaction between holders might include every director of Paranacidade, from
users and system, e.g. with the use-case model (Bittner and the executive director to the director of operations, the chief
Spence, 2003; Jacobson, 1992; 1994), is possible after officers of projects and the technicians that work for the
identifying all of the user requirements. offices. In addition to these professionals, we include
stakeholders from the municipality’s city hall secretaries
An example of requirements elicitation for a geo-information solution and the Paranacidade regional offices and from certain State
for urban planning of Paraná government secretaries. The system users are the
As an example of a possible implementation of the professionals from the project offices who are responsible for
requirements elicitation process, we illustrate our proposal setting the guidelines and methodology for development and
by describing certain aspects of the development of an revision of the MMP. The technicians of this office are
MMP in the State of Paraná in Brazil. The knowledge field experts in urban planning, civil engineering, geography,
of this geo-information solution application is urban business, information technology and geo-information
planning, and the cartographers and geo-informaticians engineering.
must learn about urban planning at a necessary level to be The objective of an urban and regional plan is to promote
able to understand the theory of the MMP, as defined in the actions for sustainable planning, employment and income
federal and state laws that rule these plans and the urban generation; improvement of the quality of life; and social
planning methodology adopted in Paraná State inclusion (Paraná, 2003). To achieve this objective, an MMP
(Paranacidade, 2010). According to the Brazilian Federal is developed in five stages (Paranacidade, 2010), of which
Constitution (BRASIL, 1988), every municipality that three stages are directly dependent on geographic knowledge:
contains more than 20,000 inhabitants is obliged to have 1. Analysis of the regional, municipal and urban reality;
an MMP, which is the basic instrument for establishing 2. Guidelines and propositions for the MMP;
policies for urban settlement and development. Since 2001, 3. Drafting of the set of laws that establishes the MMP
every MMP in Brazil must be proposed in accordance with itself.
the ‘Statute of the Cities’ – Federal Law 10257/2001
(BRASIL, 2001). The analysis of the reality is accomplished in three steps:
In the State of Paraná, it is common that the municipality 1. Data and geo-data surveying,
executive government must contract a consulting firm that 2. Geo-information structuring,
specializes in urban planning to develop an MMP. The
3. Geo-information analysis, aiming at analysis of the
proposed MMP is analysed and approved by the munici-
current state of the municipality relative to all the
pality’s technicians and sent to the municipality council of
aspects of the MMP.
representatives for approval as a set of laws. Consequently,
in the State of Paraná, there are three groups of The third step requires an understanding of the character-
professionals that could be involved in establishing and istics of physical geography, economics, history and land
88 The Cartographic Journal

use evolution as well as the socio-economic conditions and In the real-life situation of designing a geo-information
environment of the municipality. An example of spatial solution, the cartographer or geo-informatician should
analysis accomplished in the third step is definition of the describe the characteristics of the dataset that would be
geographic location and limits of the environmental accessed by the users from the geo-database, the geo-
protection areas. To define the environmental protection information scale range to be implemented, the geo-
areas, it is necessary to understand the current situation of information visualization parameters for any type of map,
the region relative to geomorphology, pedology, geology, the data classification methods demanded by the geo-
vegetation, hydrography, topography and urban and rural graphic knowledge requested, etc. However, every one of
areas. these decisions must be based on the user requirements,
The results of the third step are the inputs for a proposed and the implementation of the geo-information system
MMP that is also based on spatial analyses because it must must meet the user requirements and needs. Additionally, it
establish guidelines for political, socio-economic and is highly important to take into consideration that in the
environmental actions and the urban infrastructure and geo-domain, the user requirements and needs are always
utilities planning required to achieve results related to: dependent on how efficiently and effectively the users can
acquire the geographic knowledge necessary to make
N Management of real estate development to promote
decisions, which are related to the development of an
urban land distribution;
MMP in this example.
N Planning of urban land use and establishment of the
region for future urban development;
N Definition of social equity in urban services and
CONCLUSIONS
infrastructure distribution;
N Planning of the urban street system and rural road In this paper, we described the application of existing
Downloaded by [CAPES] at 10:28 04 October 2017

systems by taking into consideration urban and rural land techniques and methods of requirements elicitation for the
use, public transportation and other methods of trans- design of a geo-information software system. Our approach
portation; is based on the following assumptions:
N Environmental protection and sanitation;
N
N Protection of the natural, historical, artistic, cultural and It is possible to achieve higher levels of efficiency, effective-
ness and user satisfaction if the design and implementation of
archaeological patrimony;
N Definition of the regulatory and policy backgrounds for
N
a geo-information solution is based on user requirements.
Design of a geo-information solution in accordance with
building permits and parcel divisions.
user requirements characterizes it as user-centred design.
It is necessary to develop a geo-information solution and to
collect, organize and represent geo-data for spatial analysis
N A geo-information solution is a system, and therefore its
design is based on an engineering approach.
of the municipality’s current state for the design of the
MMP. In the State of Paraná, certain urban planners still
N It is possible to ascertain a basic set of geo-information system
components with characteristics and relationships established
use printed maps, although others adopted GIS several in accordance with the user requirements and the use context.
years ago. However, the GIS solutions are only used to
generate thematic maps, either printed or screen maps. For One of the important starting points of our proposal is that the
these users, the geo-information solution might best design of the entire system, including the user interface, is a
combine GIS and interactive map characteristics. Such a result of the user requirements. Therefore, the geo-information
geo-information solution would be designed to allow users system must fit the users’ needs and expectations and not the
to acquire the spatial knowledge necessary for the MMP of other way around, which would force the users to adjust and
a municipal region. adapt themselves to the system. The consequence of our
Examples of the necessary conditions and constraints of approach (which is in turn a demand for the system design) is
the geo-information system are related to the size of the that the level of user satisfaction should be high. This level of
geographic region. The MMP must be based on three levels user satisfaction is only possible if the users can learn how to use
of geographic analysis: urban, municipal and state the system independently, to acquire the geographic knowledge
(Paranacidade, 2010). Each of these levels requires a necessary to perform their intended tasks. If the user
different range of geo-information scales, and conse- requirements are completely and correctly defined and the
quently, different solutions for the geo-information com- system design is developed in accordance with those require-
ponents of the system (e.g. spatial data content, geo-data ments, the users are able to execute the tasks defined during the
content modelling, display medium, software and map requirements elicitation in their application domain.
interaction, symbology). Our purpose in describing an example related to the
The design of the geo-information system must take into development of an MMP was to illustrate how to approach
consideration that the users must make decisions based on the elicitation of requirements in a practical situation. A
geographic knowledge to accomplish their tasks. The geo- complete set of the information that would form a component
information solution should provide such functions as using of the requirements document is the objective of our future
different maps from different datasets stored in the geo- research in which we will apply the proposed framework to a
database, accessing tables and graphics related to the map, well-defined case study. The case study is the design of a geo-
performing geographic analysis, defining the map layout information system for the development and implementation of
and comparing the maps to the tables and graphics, as in a MMPs for the State of Paraná, Brazil. This case study is
geo-visual analytics system. developed in different stages in accordance with the activity
Requirements Elicitation for Geo-information Solutions 89

model of the requirements engineering process adapted to a Bray, I. K. (2002). An Introduction to Requirements Engineering,
Pearson Education Ltd., Edinburgh Gate.
geo-information solution. One of the objectives of the case
Burrough, P. A. and McDonnell, R. A. (1998). Principles of
study is to complete the requirements elicitation with sufficient Geographical Information Systems, Oxford University Press,
information to define the functionality, external interfaces, New York.
performance, attributes and design constraints imposed in an Chrisman, N. R. (1984). ‘The role of quality information in the long-
implementation of the geo-information system. Certain results term functioning of a geographic information system’,
Cartographica: The International Journal of Geographic
have already been achieved and are described in Sluter et al.
Information and Geovisualisation, 21, pp. 79–87.
(2013). The range and complexity of defining user require- Coad, P. and Yourdon, E. (1990). Object-oriented Analysis, 2nd
ments for this case study will provide us with the information edition, Prentice Hall, Englewood Cliffs, NJ.
and knowledge that will make it possible to verify whether the Cockburn, A. (2001). Writing Effective Use Cases, Addison-Wesley,
proposed guideline can evolve into a methodology. After Upper Saddle River, NJ.
Collaros, P. A. and Anderson, L. R. (1969). ‘Effect of perceived
eliciting all of the requirements for the geo-information system, expertness upon creativity of members of brainstorming groups’,
we can describe them using system requirement models Journal of Applied Psychology, 53, pp. 159–163.
(Jackson, 2006; Arlow and Neustadt, 2005; Gunter et al., Dykes, J. and Wood, J. (2010). ‘Rethinking map legends with
2000). Analysis and application of the requirement models for visualization’, IEEE Transactions on Visualization and
the description of geo-information system requirements is a Computer Graphics, 16, pp. 890–899.
Fairly, R. E. (1985). Software Engineering Concepts, McGrall-Hill,
component of our planned future research. Inc., New York.
Foley, J. D., van Dam, A., Feiner, S. K. and Hughes, J. F. (1990).
Computer Graphics Principles and Practice, 2nd edition,
Addison-Wesley Publishing Company, Inc., Boston, MA.
BIOGRAPHICAL NOTES
Gunter, C. A., Gunter, L., Jackson, M. and Zave, P. (2000). ‘A
Claudia Robbi Sluter is an reference model for requirements and specifications’, IEEE
Downloaded by [CAPES] at 10:28 04 October 2017

Software, 17, pp. 37–43.


Associate Professor in
Haklay, M. and Chao Li, L. (2010). ‘Single user environments:
Cartography and Geo- desktop to mobile’, in Interacting with geospatial technologies,
graphic Information System ed. by Haklay, M., pp. 223–243, John Wiley & Sons Ltd,
at the Federal University of Chichester.
Paraná (UFPR), Brazil. She Hull, E., Jackson, K. and Dick, J. (2005). Requirements Engineering,
2nd edition, Springer ,springeronline.com..
studied Cartographic Engi-
IEEE - The Institute of Electrical and Electronics Engineers (1998).
neering at the Federal Uni- IEEE Std 1233–1998 Guide for developing system requirements
versity of Paraná (UFPR) specifications, NY, USA.
and obtained a PhD degree IEEE - The Institute of Electrical and Electronics Engineers (2009).
on Applied Computing (Revision of IEEE Std 830–1993) IEEE Recommended practice
for software requirements specifications, NY, USA.
from the National Institute Jacobson, I. (1992). Object-oriented Software Engineering: A Use
for Space Research (INPE), Case Driven Approach, Addison-Wesley Publishing Company,
Brazil. She works on topics Reading, MA.
in use and users issues in geo-information processing and Jacobson, I. (1994). ‘Basic use-case modeling’, in The road to the
dissemination, geovisualization and geovisual cognition. unified software development process, ed. by Jacobson, I.
(2000), pp. 167–181, Cambridge University Press, New York.
Jackson D. (2006). Software Abstractions: Logic, Language, and
Analysis, MIT Press, Cambridge, MA.
ACKNOWLEDGMENTS Köbben, B. (2007). ‘RIMapperWMS: a Web Map Service providing
SVG maps with a built-in client’, in Lectures Notes in
This research work is developed in cooperation with the Geoinformation and Cartography, The European Information
Serviço Social Autônomo Paranacidade (Paranacidade Social Society: Leading the Way with Geo-Information, ed. By Fabrikant,
S. and Wachowicz, M., Part 6, pp. 217–230, New York.
Service) of Brazil.
Kotonya, G. and Sommerville, I. (1998). Requirements Engineering
- Processes and Techniques, John Wiley and Sons Ltd, New York.
Kraak, M. J. and Brown, A. (2001). Web Cartography -
Developments and Prospects, Taylor and Francis, London.
Kraak, M. J. and Ormeling, F. (2010). Cartography - Visualization
REFERENCES
of Spatial Data, 3rd edition, Prentice Hall, Essex.
Arlow, J. and Neustadt, I. (2005). UML2 and the Unified Process, Lloyd, D. (2009). Evaluating Human-centered Approaches for
Practical Object-Oriented Analysis and Design, 2nd Edition, Geovisualization, PhD Thesis, City University of London,
Addison-Wesley Professional, Boston, MA. London, UK.
Bittner, K. and Spence, I. (2003). Use Case Modeling, Addison- NASA - National Aeronautics and Space Administration (2007) NASA
Wesley Inc., Boston, MA. Systems Engineering Handbook, NASA/SP-2007-6105, Rev1, USA.
Booch, G. (1994). Object-oriented Analysis and Design with Nelson, M. A. V., Alencar, P. S. C. and Cowan, D. D. (2007).
Application, Benjamin Cummings, Redwood City, CA. ‘Informal description and analysis of geographic requirements: an
Bouchard Jr, T. J. (1972). ‘A comparison of two group brainstorming approach based on problems’, Software & System Modeling, 6,
procedures’, Journal of Applied Psychology, 56, pp. 418–421. 223–245.
BRASIL (1988). Constituição da República Federativa do Brasil - Nosek, J. T. and Schwartz, R. B. (1988). ‘User validation of
Texto consolidado até a Emenda Constitucional nu 70 de 29 de information system requirements: some empirical results’, IEEE
março de 2012, Senado Federal, Secretaria Especial de Publicações Transactions on Software Engineering, 14, pp. 1372–1375.
e Editorações, Brası́lia, Brasil. OGC – Open Geospatial Consortium (2013). OGCH Standards and
BRASIL (2001). Diário Oficial da União nu 133, República Federativa supporting documents. http://www.opengeospatial.org/stan
do Brasil, Imprensa Nacional, Brası́lia, Brasil. dards (accessed on 18 June 2013).
90 The Cartographic Journal

Paraná (2003). Polı́tica de desenvolvimento urbano e regional para o Sutcliffe, A. (2002). User-centred Requirements Engineering,
Estado do Paraná. Secretaria de Estado de Desenvolvimento Springer-Verlag, London.
Urbano (SEDU), Governo do Estado do Paraná, Curitiba, Brasil. Tsou, M. and Curran, J. M. (2008). ‘User-centered design approaches
Paranacidade (2010). Processo licitatório de Convite nu008/2010 - for web mapping applications: a case study with USGS hydrological
Plano Diretor Municipal - Municı́pio de Lunardelli - Termo de data in the United States’, in International Perspectives on Maps
referência padrão elaborado pelo Paranacidade que atende a lei and the Internet, ed. by Peterson, M., Lectures Notes in
15229/2006. Serviço Social Autônomo Paranacidade, Curitiba, Geoinformation and Cartography, Vol. 20, pp. 301–320.
Brasil. Springer-Verlag, Berlin.
Parnes, S. J. and Meadow, A. (1959). ‘Effects of ‘Brainstorming’ Tsou, M. (2011). ‘Revisiting web cartography in the United States: the
instructions on creative problem solving by trained and untrained rise of User-Centered Design’, Cartography and Geographic
subjects’, Journal of Educational Psychology, 50, pp. 171–176. Information Science, 38, 3, 250–257.
Ross, D. T. and Schoman Jr., K. E. (1977). ‘Structured analysis for Yovcheva, Z., van Elzakker, C. P. J. M. and Köbben, B. (2010).
software definition’, IEEE Transactions on Software ‘Collaborative mapping and spatio-temporal data dissemination
Engineering, SE-3, pp. 6–15.
through a web-based virtual globe application’, Proceedings of
Royce, W. W. (1970). ‘Managing the development of large software
3rd International Conference on Cartography and GIS,
systems’, Proceedings IEEE WESCON, 1–9, Los Angeles, CA,
Nessebar, Bulgaria, Jun.
Aug.
Skarlatidou, A. (2010). ‘Web-mapping applications and HCI con- Van Elzakker, C. P. J. M. (2004). The use of maps in the exploration
siderations for their design’, in Interacting with geospatial of geographic data, Utrechtse Geografische Studies 326,
technologies, ed. by Haklay, M., pp. 245–264, John Wiley & University of Utrecht, Utrecht.
Sons Ltd, Chichester. Virrantaus, K., Fairbairn, D. and Kraak, M. J. (2009). ‘ICA research
Sluter, C. R., Brandalize, M. C. B., Ivánová, I. and van Elzakker, C. agenda on cartography and GI science’, The Cartographic
(2013). Defining standard symbols for street network maps for urban Journal, 46, pp. 63–75.
planning based on user requirements. Proceedings of 26th Wealands, K., Cartwright, W., Miller, S. and Benda. P. (2005). ‘User
International Cartographic Conference, Dresden, Germany, Aug. assessment for developing optimal cartographic representation
Suchan, T. A. and Brewer, C. A. (2000). ‘Qualitative methods for models within an Australian mobile location-based services travel
research on mapmaking and map use’, Professional Geographer, application’, Proceedings of 22th International Cartographic
Downloaded by [CAPES] at 10:28 04 October 2017

52, pp. 145–154. Conference, La Coruna, Spain, Sep.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy