"BEST-GIS" ESPRIT/ESSI Project n. 21580

5. Checklist for selecting and defining user requirements for specific GIS applications  
  
The near future will probably see the definition of proper requirements representation models conceived for a direct use by the end user. However, much can already be done starting from the current practice by taking advantage of the experience gained in many different GIS projects.   
We consider a significant step forward the possibility, for the user, to collect alone his/her own requirements. A very simple and familiar mean to help the user in this task is providing him/her with a checklist that recalls all the main requirement collection aspects.   
  

5.1 Task rationale and procedure for criteria identification   

Requirements specification with the guidance of this checklist if communicated to the developers is the beginning of a full user-centred application development.   

Two general considerations hold, and must be kept in mind defining the checklist:   

  • The image the user has of a GIS application is exactly that resulting from the application interface. All what happens on the interface is matter of requirement specification, the rest being left to the developer experience. 
  •  A GIS application is usually aimed at deriving information, a new map, from the data available in the geographical database. The user describes to the application developer the characteristics of the map to derive and the sequence of operations to perform on the available data. 

It is unlikely that the user alone or the application developer alone are able to propose a valuable and complete checklist, at least for two main reasons:    

  • the end user has a deep knowledge of the application domain and of the problem to solve, but normally s/he is not used to express his/her requirements; 
  • in turn, the application developer is interested in collecting and interpreting the user needs with the aim of identifying the most convenient solution to them. 

        
The userās contribution to the checklist are the indication of requirements for single GIS projects and the final checklist validation and improvement activity.   

The application developerās contribution is mainly focused on providing practice knowledge from which a project design best practice can be drawn.   
A further contribution may come from those organisations that play the role of intermediary user, with respect to technology providers and application developers.   

The  procedure to identify  the requirement specification criteria is  based on four main steps:   
            1. Prepare a tentative checklist  as synthesis of experiences and practices available;    
            2. Submit   the checklist to users for validation;   
            3. Improve the checklist using the validation results;   
            4. Disseminate the checklist to collect further comments from a wider audience and provide to  
                its periodic improvement, extension and possible specialisation.    
  

5.2 How to use the checklist  

The collection and specification of requirements for a GIS application  should be as much as possible complete and unambiguous. For very complex and innovative systems (like GIS applications are) a full Requirement Specification (RS) is needed as a basis for feasibility estimation in order to reduce contractual risks.    

The RS output should present all the system functional and non-functional requirements and indicate design and implementation directives of the intended application:   

  • Functional requirements display the functionality of the application. It means making explicit the actions and operations the application must provide to the user. 
  • Non-functional requirements tend to be constraints that the completed system must fulfil. 
  • Design directives are user constraints upon the structure of the system solution. 
  • Implementation directives constrain the developer by defining choice of implementation language or database management system. 
  • While the checklist proposed in this section deals with the first two points, design and implementation directives are considered in sections 6 and 7 of these Guidelines.   

  • The RS document is the synthesis of  the viewpoints of the different identified application users. There are two alternative ways of using the proposed checklist to derive the synthesis requirements:   
     
    • Every user collects and specifies his/her own requirements, then the resulting documents must be discussed and unified into the final RS document. Advantages are the total freedom of the single user and  the completeness of the final document. The main drawback is the redundancy of the specification work as many users may give the same indications on many points.   
    • The users organise meetings for the different sections of the checklist with the purpose of discussing the requirements point by point. The outcome of this work is directly the final RS document. A first importantby-product of this approach is a very early constitution of a working group where all the members are aware of  the common interest and objectives. The drawback is that some users tend to become meeting leaders and impose their viewpoint.   

    A checklist scheme is proposed as a guide to derive an actual checklist.    

    Completing the checklist its granularity, that is the degree of detail of its points, may  be chosen having in mind two contrasting objectives: completeness and applicability. The former objective is pursued by splitting the requirement collection into general (steady) aspects and other (evolving) aspects related to single application fields. The latter takes advantage of the checklist organisation into homogeneous modules that should focus the user attention on clear and distinct subjects.   
    An interesting direction to follow for making this checklist more and more effective is that of its specialisation by type of application field. These applications can hence increase in number and richness of points and thus constitute the principal evolution path for the checklist itself.  
     

    5.3 Checklist of functional and non-functional requirements  

    General requirements  
    This concerns the specification of some general requirements aimed to satisfy fundamental user needs. These  requirements  have to be accomplished not  only in GIS projects, but in almost any type of software based project.   

    Project organisation requirements   
    This section concerns the specification of requirements relative to the project intended as a whole and its organisation and control. Because of the general view it suggests, this section essentially refers to non-functional requirements.   

    Project outcome requirements  
    This section is intended to be replicated for every single result (typically, a derived map) expected from the GIS project execution. Main aspects are the explicit definition of the output map itself, the associated descriptive and quantitative information and the representation of possible constraints on its use and diffusion.   

    Map acquisition requirements  
    This section expresses the requirements on how to obtain the basic maps that constitute the input to the GIS project.    
    A complete identification of the input maps is fundamental to plan the application development work. We suggest paying much attention to this aspect since the acquisition of geographical data is a very time and resource consuming task.   

    Derivation process requirements  
    This section is aimed at pushing the end user to express his/her own idea on how each GIS project outcome can be obtained from the input maps. This information should be replicated for every output map, although some phases can be common to more derivation processes.    

    User interface requirements  
    This section concerns the specification of requirements relative to the final user interface. The user interface defines the way to access geographical data. Customisation of interface plays an important role for the usability of the system, defining the basic interactions with data.    

    Map visualisation requirements  
    This section collects the requirements on the desired aspect of map rendering. At least three different representation media should be considered: display, paper and the Internet.   

    Database organisation requirements  
    This section is intended to provide help in evaluating the requirements for databases associated to a GIS project.    
    The database main goal is here to hold information that cannot be adequately represented in a graphical manner, and to provide an alphanumeric integration of graphical information.    

    Application oriented requirements  
    More than one section may be inserted. This type of section represents an example of specialised points with respect to the single application context. Here the focus is on content and method issues that are typical of the considered context. Example of application fields are Environment Control and Urban Planning. 
       
      
      

    • Copyright © the EUROPEAN COMMISSION