DETERMINATION OF GEO-INFORMATION CHARACTERISTICS IN THE USER INTERACTION WITH A SYSTEM FOR BETTERMENT TAX CALCULATION

In this paper, we present some results of research work that seeks to determine how the characteristics of geoinformation should be considered and included in the design of users' interfaces for a geoinformation system. Through well-known techniques of requirements engineering, we collected and documented the information obtained from potential users of a geoinformation system designed to be used for calculation of betterment taxes. Furthermore, we analyzed the users’ requirements to determine the characteristics of geoinformation in this particular case of tax calculation. We try to define how those geoinformation characteristics can be included in the requirements specification and how to consider them to help designing better geoinformation systems interfaces.


Introduction
In the last decades, researchers have pointed out that the production and use of maps is no longer an exclusive task of cartographers or geo-information experts (Green 1993, Brus, Dobesova, Kanok and Pechanec, 2010, Brown et al. 2013).Technological advances in GIScience and Cartography, together with the easiness in acquisition and use of geographical information systems (GIS) and spatial data, have contributed to a large dissemination of geo-information, which allows virtually anyone to create cartographic products.However, significant problems can be observed, as a consequence of spreading geo-information in different human activities: the lack of theoretical knowledge in cartography results in cartographic products with communication problems (Green 1993), deficiencies in understanding the significance of data (and thus their analysis), lack of context for data use or data control (Brown et al., 2013), usability and interface interaction problems (Yun and Yufen, 2011), to point out a few.Among many different users of spatial information in Brazil are urban planners and technicians that are responsible for taxation policies, such as the betterment tax.To be efficient and in accordance with Brazilian laws, those tax policies have to be proposed based on correct and precise spatial analysis.Besides, the collection of taxes directly affects taxpayers and thus the whole society.Therefore, the knowledge acquired by technicians and planners, when interacting with geographical information systems, must be correct for the required application of taxes.Thereby, the users' needs, responsibilities, tasks, expertise and degree of cartographic knowledge must be considered in the geo-information solutions.
For that, we propose a Requirements Engineering (RE) approach to the design of interfaces for a geographical information system applied to the calculation of betterment tax.Despite being widely used in computational sciences, RE in GISciences has been neglected.There are only a few scientific papers describing research results in the area and a sound methodology that considers geographical information singularities in the RE process is still missing (Sluter,van Elzaker andIvanová 2016, Lloyd 2009).Based on guidelines and adaptations from well documented practices found in the RE literature, proposed by Sluter et al. (2016), we intend to understand how geoinformation affect system requirements description, and what can be changed or modified in the documentation process to include geo-information.This paper is divided in three parts: first we introduce the requirements engineering process and methodology used in the research; then, we present the results obtained with the application of these methodology in a betterment tax calculation situation; last, we conclude the paper, and provide suggestions for future research.

Requirements Engineering Process
The methodology used in this research for RE was based on Sluter, van Elzaker and Ivanová, (2016) which was adapted from Kotonya and Sommerville (1998) guidelines for the writing, analysis, validation and management of requirements.Kotonya and Sommerville (1998) proposed a set of four activities to be performed in the RE process: requirements elicitation; requirements analysis and negotiation; requirements documentation and requirements validation.Focusing on the elicitation process, Sluter, van Elzaker and Ivanová et al. (2016) presented a model of activities of RE process for geo-information solutions.By setting out a series of questions, the authors intended to guide the requirements elicitation process.Using these questions, together with literature review on the knowledge domain, documentation analysis, brainstorming sessions with experts in the subject and interviews with the system stakeholders, we managed to gather not only users' requirements for the system, but also an understanding of its use context.
The next activities consisted of the analysis and negotiation of the elicited information.These two methodology steps allowed us to discover new requirements previously omitted, requirements conflict, ambiguities, overlapping requirements or even misleading and unreal requirements, that is, the requirements that were impossible to be achieved (Sommerville and Sawyer 1997).All the information was checked and analyzed, so every element and its implications were defined according to the system goals.In this research, we focus on checklists for requirements analysis and conflicts resolution planning as a requirements negotiation technique, both proposed by Sommerville and Sawyer (1997).In the first, the elicited requirements were checked to verify requirements combinations, unnecessary requirements, conformity with the system objectives, ambiguous requirements, and requirements testability.In the last, requirements conflicts were discussed together with the stakeholders seeking an agreed solution.
To help understanding and visualizing users' activities when interacting with the system, we used the Unified Modeling Language (UML) Use Case view.As stated by Jacobson, Booch and Rumbaugh (1999), "use case view models the functionality of a subject (such as a system) as perceived by outside agents, called actors, that interact with the subject from a particular viewpoint".It represents a partition of the system functionality, and is intended to present its behavior in relation to the user interaction, without showing the system internal structure.
The third activity of the RE process was the system requirements documentation.Also, known as System Requirements Specification -SyRS (ISO, IEC and IEEE 2011), the requirements document was meant to officially inform the customer requirements to the technical community of developers that will further create the system.It's a "structured collection of the requirements (functions, performance, design constraints, and attributes) of the system and its operational environments and external interface."(ISO, IEC and IEEE 2011).Also, this collection of requirements should act as a bridge between the stakeholders and the technical community, and thus need to be understood by both groups (ISO, IEC and IEEE 2011).
The Institute of Electrical and Electronic Engineers (IEEE) provides worldwide used standards for requirements specifications.Together with the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), the IEEE released in 2011 the International Standard ISO/IEC/IEEE 29148:2011: Systems and software engineering -Life cycle processes -Requirements engineering, unifying the processes and products involved in requirements engineering throughout system and software life cycle (ISO, IEC and IEEE 2011).
Since we analyzed only the interaction related requirements, other kinds of requirements stated in the ISO/IEC/IEEE standard were disregarded, such as performance requirements, security requirements, environmental requirements, among others.
Last, the validation process aims at providing a confirmation of the information gathered, ensuring that the requirements document is complete and understandable to all the stakeholders.For that we used scenarios, or a sequence of steps explaining the activities to be performed.The scenarios structure was adapted from Robertson and Robertson model (2012, p.129-145).The main goal of using this approach is to consolidate the collected requirements, and present to the user a controlled situation of system use, at the end of which we will be able to evaluate the elicited information together with the users' needs and vision for the system interfaces.With the conclusion of the validation process we will have sufficient information to maintain or refute the elicited Determination of... Bull.Geod.Sci, Articles section, Curitiba, v. 23, n°3, p.476 -492, Jul -Sept, 2017.requirements.

Information Gathering
In the requirements elicitation process, we worked together with experienced urban planners from the Habitation and Urbanism Laboratory (LAHURB) of the Federal University of Paraná.To focus on a real case application, we proposed a case study for the development of system interfaces.We identified the potential final users of the system as being municipality technicians from Campo Grande city, the capital of Mato Grosso do Sul state, Brazil.Betterment tax is used in Campo Grande city since 2000, and it is well grounded in the municipality legislation.However, a study shows that in the period of 2000-2012 the amount collected from betterment tax represented only 1,25% of the municipality tax revenue (Silva and Pereira 2015).
The betterment tax is a tribute levied specifically for land valuation capture.When a public investment in infrastructure (construction, widening and paving of roads; construction of parks and squares, bridges, overpasses, underpasses, walkways and tunnels; construction of underground transport systems) is made, the value of the nearby private properties tend to increase, due to the availability of the new service.However, these private parcels valuation is undue and unfair, because its source is a public investment.Therefore, the land valuation capture is intended to return to the society part of the amount invested in urban infrastructure (Smolka 2014, Pereira et al. 2013).
Despite being well grounded on Brazilian laws (such as the Federal Constitution, National Tributary Code, Municipalities Tributary Code), the betterment tax is rarely used and collected in the country.According to Pereira et al. (2013), the betterment tax collection in the period between 2000-2010 represented only 1% of all properties tributes and taxes raised in the country.Smolka (2014) reports that some of the reasons for that are the difficulties in the definition of the impacted area and the identification of affected parcels, issues in the definition of the total value to be charged, together with problems in the distribution of this amount to each affected parcel.Those problems, besides the different legal sources of the tribute and the ignorance of the practices and methodologies by the technicians responsible for its application, contribute to the low usage of betterment tax.
Thus, the objective of the proposed system is to help municipality professionals, among them the urban planners, in the calculation and charge of the betterment tax.Through the system usage, the user should be able to define the area benefited by the urban infrastructure, and to calculate the valuation of each benefited parcel.At the end, the system outcome should be a spreadsheet containing the benefited parcels address, its owner, the land cost, and the amount of betterment tax to be charged in each case.These elements should be presented to the target population so they can be aware of their situation.Last, the information (parcels, owners and values) must be passed on to the administrative sector of the municipality which will take charge of the tax collection.
Therefore, to collect information about the users' needs and the domain application for the system, we presented to the stakeholders a series of questions adopted and adapted from Sluter,van Elzaker and Ivanová (2016) proposition.We managed to obtain the following answers: 1) Users activities Question (Q): What are the users' responsibilities in the defined use context?Answer (A): To determine the betterment tax to be charged from parcels located inside the Bull.Geod.Sci, Articles section, Curitiba, v. 23, n°3, p.476 -492, Jul -Sept, 2017.influence area of an urban infrastructure investment.
Q: Which are the activities required for the users' to achieve those responsibilities?A: Define the urban infrastructure investment; delimitate the influence area; determine parcels that are exempt of charge by law (parcels belonging to the public authorities, religious temples, buildings of political parties, buildings of education institutions and social assistance, parcels of owners financially capacitated of paying the tribute); determine the parcels value (before and after the public investment, valuation); determine the investment cost and its partition between all benefited parcels; define the value to be charged; elaborate notification notice; conduct public hearing together with the benefited owners; elaborate a release notice of the tribute.
Q: What is the background knowledge of the users' activity?A: Mainly urbanism, land valuation, betterment tax and its application, Brazilian tax legislation (federal, state and municipal), structure of municipal cadastre.
2) Problem to be solved Q: What is the problem to be solved?A: The main problems to be solved by using the system are: determine the amount of betterment tax to be charged as a result of an urban investment in infrastructure; overcome the lack of theoretical knowledge regarding the application of the betterment tax; help identifying the major difficulties in the application of the betterment tax; address the lack of information by managers and technicians in the applicability of the betterment tax; provide theoretical and operational comprehension of the betterment tax application.
Q: What required geographic knowledge is related to the problem?A: Geographic knowledge about the area to be applied the tax, such as the location of the urban investment in infrastructure, and its surroundings (road system, neighborhoods, urban zoning, hydrography); urban parcels divisions and dimensions (area, perimeter, frontage); location of urban equipments (like parks, squares, etc.).

3) Geo-information solution constraints
Q: What are the geo-data conditions that are required to solve the problem?A: Geo-data must be updated, reflecting the urban reality in the moment of the betterment tax charge.Furthermore, the geo-data must be referred to a single spatial reference system and map projection systems officially adopted by the municipality, in this case Sirgas2000 and UTM, zone 21 South.
Q: What are the constraints for the geo-data and the geo-information system that are required by those conditions?A: Out of date data may result in errors in the distribution of amount of betterment tax to be charged.Therefore, data must be update, preferably provided by the municipal government.
Regarding the spatial reference system, constraints refer to the need of adopting a single system for all data used and generated.4) Objectives of the geo-information system Q: Based on the activity goals, the problem to be solved and the solution condition and constraints, what are the objectives of the geo-information system?A: To calculate the amount to be charged in betterment tax from parcels located inside the influence area of an urban infrastructure investment.Beyond that, the geo-information system must be able to create notifications (to be presented to the community in a public Determination of... Bull.Geod.Sci, Articles section, Curitiba, v. 23, n°3, p.476 -492, Jul -Sept, 2017. hearing) and release notices from which the charge will be made.

5) Stakeholders and users' identification
Q: Who are the stakeholders in the application domain?A: In this application, we identified two groups of stakeholders.Those directly involved with the system are: The Campo Grande municipality technicians; researchers of the LAHURB; and researchers from the Cartography Laboratory (LABCARTO), from the Federal University of Paraná.Indirectly, the application domain reaches the responsible for the municipality public policies, and ultimately the community (tax payers).
Q: Which characteristics of the stakeholder must be considered in the geo-information system design?A: The professional qualifications and experience of the stakeholders, and the degrees of theoretical and practical knowledge on both urbanism and public policies.
Q: Among the stakeholders, who are the geo-information system users?A: The system users are the municipality technicians, working in different sectors of municipality administration.
Q: What are the users' responsibilities and tasks in their activity context?A: To create a document informing the parcels to be charged of betterment tax, as well as the amount to be charged for each parcel.This document will be used as a reference for the tax payment.

6) Goal prioritization and domain knowledge filtering
Q: What geographic knowledge do the users need to build up?A: The users must determine: a) the location of the urban investment in infrastructure; b) the parcels that benefit from this urban investment; c) the benefited parcels' dimensions; d) the distance between the parcels and the urban investment (in some cases, the amount to be charged varies with the urban investment proximity).
Based on the above answers, we were able to establish a starting point for the knowledge construction related to the system objectives and application domain.Moreover, we could conduct this knowledge construction in terms of the elements initially set, accessing and analyzing the specialized literature, together with brainstorm and discussion sessions along with the stakeholders.
According to the information gathered from the system stakeholders and the specialized literature (Brasil 1967, Pereira et al. 2013, Smolka 2014, Silva and Pereira 2015), the event that triggers the betterment taxation is the increased value of some land that is located in an area that has been benefited directly or indirectly from a public investment in urban infrastructure.The types of urban infrastructure that are usually charged by betterment taxes are (Pereira et al. 2014): • the construction, widening and paving of roads; • the construction of parks and squares; • the construction of bridges, overpasses, underpasses, walkways and tunnels; • the construction of underground transport systems.
At the end of the urban infrastructure construction, it is necessary to define its benefited area.This definition depends on the type of the urban infrastructure.There are mainly two types of urban infrastructure that have been considered for betterment taxation in Brazil (Pereira et al. 2014): linear or radial influence urban infrastructure.The linear influence urban infrastructure, such as the construction, widening and paving of roads results in a longitudinal benefited area.The affected parcels are only those that are in front of the urban infrastructure, as shown in red on Figure 1a).On the other hand, the radial influence urban infrastructure, like the construction of squares, and parks; bridges, viaducts, walkways, and tunnels, results in a radial benefited area centered in the infrastructure itself.The affected parcels are located inside these radius (Figure 1b).More than one radius are defined, according to the proximity to the infrastructure: the properties located inside the inner radius (as shown in darker red on Figure 1b), are subject to a greater land valuation, and thus, to a greater tax charge.After the definition of the benefited area, and thus the affected properties, the technicians need to define the tax value to be charged, which is one of the major difficulties in the process of betterment taxation.The main reason is that this definition depends on two distinct values: the total cost of the urban infrastructure shared among all the benefited properties, and the properties valuation amount.The amount to be charged as betterment tax is defined as the lowest of those two values (Pereira et al. 2014, Smolka 2014, Ramos 2016).
The valuation amount represents the difference between the parcels values before and after the construction of the urban infrastructure.The value of each parcel is determined by two distinctive elements: the property characteristics (area, frontage, perimeter); and the land value per square meter, defined by the municipality government.
After the definition of the amount to be charged, the next step is the owners notification.The benefited community is invited for a public hearing, where the calculated values are informed to each parcel owner.Also, one of the public hearing goals is to identify the owners that do not have financial resources to bear the tax.Those are included in the tax-exempt situation, together with those exempted by law (parcels belonging to the public authorities, religious temples, buildings of political parties, buildings of education institutions and social assistance).
With the public notification and identification of tax-exempt owners, the next and final step of the process is gathering all information in a release notice, through which the tax collection is executed.
In this research, we have defined tools to be used in planning the interactions required for each of the steps above, according to the users' needs.Since this proposed system is meant to be used by a municipality and is developed in an academic environment, its cost of implementation was considered to decide about the tools for the design of the interfaces.Therefore, one of users needs was that the system should be implemented using open source and free software tools.As a result, we adopted QGIS, a free and open source geo-information tool for the geo-information analyses and manipulation of the geodata related to the infrastructure location and benefited parcels.QGIS is widely used in the GIS community and has the advantage of been largely customizable.
Likewise, we adopted Qt Designer, as a tool for the design of the graphical user interfaces.Those two tools together (QGIS and QtDesigner) can provide a large variety of possibilities for the modification and building of specific solutions, according to users' needs.
Also, since we defined the Campo Grande municipality as being the system application area, we collected geo-information layers, features and shapefiles required for the correct analyses and tax definition, Those are related to urban streets and roads, watercourses, green areas, properties (urban cadastre), blocks division, municipal neighborhoods, urban perimeter.Each one of those features were represented by a geographical element and its attribute table.Those geo-data are available in the Municipal Secretariat of Environment and Urban Development (SEMADUR) website (http://www.pmcg.ms.gov.br/SEMADUR).Also, the symbology to be adopted for each feature was discussed and defined by the users' needs.The symbols should be easily understood by the user.Therefore, we proposed the adoption of two symbology conventions produced in Brazil: one for medium scales and one for larger scales.For medium scales (from 1:250.00 to 1:25.000), we proposed the symbology conventions created by the Brazilian Army Geographic Service Board (DSG, 2000), which is used for the topographic mapping.For large scale symbols, we proposed the adoption of the conventions created by Paraná State Technical Chamber of Cartography and GIS.

Users Activities
We have identified four main activities to be performed by the system users: a) the creation of the project and insertion of the infrastructure investment location into the system; b) the definition of the benefited properties; c) the creation of the disclosure notice and the holding of the public hearing with the community; and d) the consolidation of the information, allowing the issuance of the release notice.The Use Case diagram below (Figure 2) present these activities and the actors involved.Specific details from each use case can be found in Ramos (2016, p.57, 66, 72 and 74).Based on those defined activities, we started discussing the users' interactions required to execute each one of those activities.Since the system is meant to be used by technicians through a desktop computer, the interactions require a keyboard and a mouse, in addition to its monitor screen.
Once we defined the geo-information tool to be used, and according to the users' needs, the initial interface of the proposed system is composed of the basic components of QGIS (the Menu bar; the Tool bar, with the following tools: File, Map navigation, Digitizing and Edition, Help; Map view; the Map legend; and the Status bar), together with tools designed specifically for the betterment tax calculation application.
The user must be first presented with a visualization of the whole urban perimeter, to have a broader view of the municipality.Also, other information such as neighborhood division, water resources and green areas (parks, woods forests) should be viewed in this initial view.At this point, the visualization scale was determined according to the dimensions of the urban perimeter (approximately 27km x 24km) and its size in the monitor screen (14 inches widescreen, approximately 31cm x 17,5cm), and thus was defined as 1:150.000(Figure 3).In the first activity, the user needs to create a project for the urban infrastructure to which he desires to calculate the betterment tax.Information need to be inserted to identify the project, the type of urban infrastructure, the construction cost and location (Figure 4): the official name of the urban infrastructure; the type of urban infrastructure; the investment cost; and the infrastructure location.The information about location allows the visualization of the urban infrastructure site, making possible for the user to edit and thus insert the infrastructure into the system.This visualization can be made in two different ways: directly through the infrastructure address, or through a neighborhood approach.In the first case, we assume that the infrastructure can be located by a single address inside the municipality.In such case, the insertion of the address into the system should, in response, present a view at 1:1.000 scale of the infrastructure location.
In the second case, we assume that the urban infrastructure cannot be located by a single address.Such is the case for extensive and complex street systems, and therefore the infrastructure site must be located by its surroundings: the user insert the neighborhood name to locate the nearby area of the infrastructure and approach the viewing through a set of different scales.We determined two intermediate scales: 1:50.000,defined based on the biggest neighborhood dimensions in Campo Grande city (7km x 8km); and 1:10.000 because it allows a more detailed view of the urban infrastructure and its surroundings.
From both methods, the end scale is 1:1.000, and from there the user can edit and insert the urban infrastructure feature into the system.Figure 5 shows an urban infrastructure already inserted in the system, both for a linear influence urban infrastructure and for a radial influence urban infrastructure.After the insertion of the infrastructure in the system, next activity can be done.In the second activity, the user must insert the benefited area into the system.In the current stage of research development, the definition of the benefited area was an external task, executed by another department of the municipality.The system user receives a spreadsheet with all the benefited parcels and inserts this information within the system.This process is executed through a Table Join function, which links the information of the spreadsheet with the geographic layer of the parcels that comes from the municipality urban cadastre.As a result, we have a new geographic layer of the benefited parcels.We proposed an interface for this task, to facilitate user interaction (Figure 6).
It is important to point out that, together with the benefited parcels, in the actual stage of the research we are not considering the calculation values in the process.Again, those calculations are realized by the administration department of the municipality, and inserted into the system in the same spreadsheet as the benefited area.After the Table Join operation, the values will become attributes of the benefited parcels layer.
Since the intended user of this system is a municipality technician, and thus not necessarily an expert in geo-information systems and database operations, this Table Join interaction should be an internal operation of the system.The only interaction required, as shown in the Figure 6, is the selection of the spreadsheet containing the benefited area.With this selection, the Table Join process is realized.By the end of this task, the system presents the new information: the layer of the benefited parcels (Figure 7).For linear infrastructures, only the adjacent parcels are benefited, as can be seen in red on Figure 7a).For radial infrastructures, different radius are defined, centered on the infrastructure (Figure 7b).The closer to the infrastructure, the higher the valuation of the parcel (as can be seen in darker red on the Figure 7b).With the creation of the benefited parcels layer, the third activity represents the collection of the parcels data in a preliminary document, and the presentation of this information to the affected community through a public hearing.Those data are represented as attribute of the benefited parcel layer, and need to be combined in a single document to facilitate its understanding by the people, unfamiliar with geo-information.Based on the elicited requirements, we proposed an interface for the assemble of those data (Figure 8).The idea is to present not only the values to the community, but also the maps.The combination of the values (numerical data) together with the visual information (more specifically the information about the urban infrastructure and the benefited area, as show in Figure 7), can help people to understand the tax, the reasons of the charge and the amounts to be charged in each case.The public hearing objective is to bring the population close to the municipality decisions, allowing them to have an active participation in the community.Finally, the fourth activity refers to the consolidation and verification of the gathered information.
All data is verified and analyzed, together with the information acquired in the public hearing decisions.Those data are then assembled in a spreadsheet which is transferred to the municipality administration, enabling the tax charge.

Geo-information Constraints and Conditioners
From the information gathering and the users interactions with the system, we were able to identify geo-information characteristics that have significant role in the interface.First, the cartographic data (layers) presented in each activity were defined according to the proposed scales and the amount of information required in each case.Also, the data quality (completeness, accuracy, update, consistency, resolution) had to be considered when choosing the cartographic data.Most of the selected data were out-of-date: they were two or three years old.This period can produce significant changes in the urban structure that can affect the tax calculation.
Also, an important element to be considered was the spatial reference system to be adopted for the cartographic representation.Since 2015, Brazil adopted SIRGAS2000 as its official reference system.Once the system is meant to be used by a municipality, we considered that the official reference system should be adopted in this research.
Another aspect considered in the research was the symbology to be used.The understanding of the geo-data presented in each interface was crucial for the users' interaction and the correct execution of each activity.The user must intuitively relate the represented symbol with the local landscape, to avoid misunderstandings.Therefore, as mentioned before, we adopted the cartographic conventions created by DSG (medium scales) and by the Paraná State Technical Chamber of Cartography and GIS (larger scales), since they relate the symbols characteristics (color, form, texture) to the element it tend to represent.

Documentation
From the definition of the users' activities, and based on the elicited information, the problem to be solved and the system objectives, an initial requirements document was created, accordingly to the ISO/IEC/IEEE system requirements specification pattern.We identified the system characteristics related to its functionalities (functional requirements) and those related to conditions and constraints of system interaction (non-functional requirements).The interface related requirements have been described and written to be understandable to all users (refer to Ramos, 2016, appendix 1 for more information about the requirements documentation).
Since the requirements engineering is an iterative and cyclical process, the initial requirements documentation was modified and corrected in the process, accordingly to users' needs.The validation step brought new insight on the system and, thus changes were made.

Validation
The requirements validation was performed through the application of usage scenarios.We proposed two hypothetical scenarios in which users should interact with the proposed system, executing the activities described in Section 3.1 -Users Activities.One of the scenarios was developed for a linear influence urban infrastructure (road paving), and another for a radial influence urban infrastructure (public square construction).In each scenario, the users had to perform all four activities through a set of steps intended to reach its desired outcome.However, since a prototype of the system was not implemented in this stage of the research, the usage scenarios were only visual, with no actual system usage.They were prepared using the proposed interfaces and the geo-data, and the responses were emulated according to the objectives and desired outcome.Those scenarios were then evaluated to determine if the requirements engineering process and the interfaces proposed were satisfactory or if more information was necessary.Four urban planners from LAHURB participated in this validation stage.
Comparatively, both scenarios presented some differences which influenced the user interaction.For instance, the type of the urban infrastructure affects the insertion of the initial textual information, the edition of the urban infrastructure and the definition of the benefited area.Also, the users' interaction changes depending on which information about the location is inserted into the system -address or neighborhood.
From this validation process, we could confirm that the gathered information was defined in accordance to the system main objective.Also, we acknowledge that the requirements documentation correctly defined the user's needs in interface.Through the validation scenarios the users had the opportunity to analyze the system's designed functionalities and responses, but above all we could confirm and refine the collected information about users' requirements.

Conclusion
The research presented in this paper aimed to provide tools for the design of geo-information system interfaces to be used in the calculation of betterment tax.Guided by Requirements Bull.Geod.Sci, Articles section, Curitiba, v. 23, n°3, p.476 -492, Jul -Sept, 2017.
Engineering knowledge, we collected information from the user's of the proposed system and, according to their needs, we suggested interfaces be adopted to fulfill those needs.
The elicited information provided knowledge on urban planning and land valuation capture policies, allowing us to determine the use context of the system, the users activities and needs.Also, we were able to identify the geo-information required to achieve the desired goals.
The requirements engineering process enables the understanding of the information required for the system creation (Kotonya and Sommerville 1998;Hull et al. 2005;Sommerville 2011).The knowledge of the application domain and the expected use of the system contribute to its effective creation and application.Therefore, the appropriation of requirement engineering expertise for the creation of geo-information systems grant the planning and development of systems for geoinformation users.
The betterment tax calculation process has multidisciplinary elements, gathering expertise in urban planning, cartography, urban legislation and taxation.The analysis of those elements must be coordinated and synchronized in the system creation.Thus, the contact between professionals from different areas of expertise, demanded by the requirements engineering, allows a better planning of the system, its use and expected results.
From the elicited information, we identified important geo-information elements for the system to be designed.For instance, the choice of a free and open source geo-information tool was very attractive, since software licenses costs could be reduced and/or eliminated.The definition of the geographical feature needed, together with the visualization scales, allowed the proposition of the interaction solutions.
The understanding and definition of the users' activities have favored the description of the requirements, enabling the identification of functional characteristics of the system (functional requirements) and separating them from the conditions and constraints imposed by the characteristics of the system interaction (non-functional requirements).
From the definition of the users' activities, and based on their objectives and needs, we were able to propose interfaces for the achievement of each of those activities.Since the users had an active role in the system design, those interfaces were modeled according to their necessities, considering their capabilities and expertise.
The inclusion of the community in the tax definition process through the use of the system in public hearings could grant the active participation of the population in the urban development.
Finally, this research was meant to be an initial requirements survey.Further inquiries and investigations should be conducted to deepen the use of requirements engineering for geoinformation systems.We treated only interaction requirements applied in the betterment tax calculation.Other users, in other contexts might need different approaches for their problems, and they need to be considered individually.
Also, it is worth mentioning that, at this point, the interfaces were not implemented.They were designed in accordance to the user's needs and requirements, but are not yet operational.System architecture and internal design were not covered in this research and should be the next stages of development.
We recommend for future studies: • the development of the systems' design and architecture; • the construction of a full prototype, to analyze the whole proposed system; • the incorporation of the definition of benefited area as a system functionality, together with the tax and other values calculations; • the implementation of users' interfaces; • the consideration of other requirements in the system creation process, such as performance requirements, environmental requirements, system operations, system security, etc.; • the consideration of the population as a stakeholder of the system, thus incorporated in the requirements engineering process.

Figure 1 :
Figure 1: Example of urban infrastructure with respective benefited area: a) linear influence area and b) radial influence area.

Figure 3 :
Figure 3: Initial view of the system.

Figure 5 :
Figure 5: Urban infrastructure: a)linear influence infrastructure and b) radial influence infrastructure.

Figure 7 :
Figure 7: Benefited area: a) linear influence infrastructure and b) radial influence infrastructure.