ATI Database Planning & Requirements Analysis

 ATI Database Planning & Requirements Analysis

This is the Situation Analysis phase which can lead to the Conceptual Design task in the Database Design phase. Exhibit below shows the Database Application Life cycle. This blog will deal with the first two tasks of the life cycle.
It is critical that all stakeholders are involved in the Situation Analysis phase because it will define the core requirements for the site development team. The stakeholders are all the users in the organization from the secretaries to the senior executive responsible for the delivery of the system. The entire group should participate in the planning process and the requirement collection and analysis.



The results of the situation analysis will form the foundational information for the application developer to begin the creation of the information system. The more accurate and clear the results of the situation analysis are the better the resultant system should be.

Clarification of terminology:

  • Database - the automated system that is implemented. It is not just the back end database.
  • Automated system - is the complete system that includes the front end, middle ware and back end.
  • Front end - this is what the user sees when the select the URL link to the site.
  • Middle ware - this is the application software that links the front end to the back end.
  • Back end - this is the physical database application that stores and manages the digital that is entered into the automated system (Database).
  • The Database could be referred to as a website, data, information or knowledge portal.
  • etc.

Database Planning

This is a very important task that is not given the time and human resources that is needed to plan the system properly. This task needs to get the input of all the stakeholders including users, operators, developers, managers and the technical support team. The degree of input may vary but the input should be gathered nevertheless. This could be completed through short meetings or workshops that will answer some of the following questions:
  • What is the purpose of the automated Database system?
  • What existing manual process is it going to replace?
  • What hard copy forms are needed to be replaced by the digital system?
  • How is this going to work?
  • Who is going to be responsible?
  • How is going to be maintained and updated?
  • What is our budget?
  • Is it sustainable (do we have sustained funding)?
  • What outputs do you expect from the system?
  • etc.

Requirements Collection & Analysis

Requirements Collection

This is where you collect all the documents, forms, guidelines and manuals of the existing manual process you are trying to convert. The most critical information are the input and output forms that are currently processed that you want automated. 

Requirement Analysis

After you have gathered all the hard copy documents and forms you can start the requirement analysis. Some of the questions can include determining:
  • What database fields do you need to replace the manual form entries.
  • This should be repeated for all input forms and resultant reports that are created.
  • Note what you can write in a paper form may need to be changed to fit the digital entry.
  • etc.

1. Create schematic of the primary document flow process.
2. Assemble all forms, define fields and attributes for data entry.
3. Conceptual relational database schema.
4. Discuss potential ICT companies for the portal development.
5. Decide on the hosting, and scenarios for post implementation operations & maintenance.
6. Review existing access to information portals to list features you would like to incorporate.
7. Use these sites to check input fields for comparison.
8. Discuss the pros and cons of the web framework to be applied, e.g. Wordpress, Drupal, etc.
9. Complete process flow diagrams.
10. Check existing Guidelines for additional data fields required, e.g. timelines, sign off fields, acceptance fields by applicant, etc.

Reference Access to Information Sites

The follow Access to Information Portal sites may be reviewed and used as reference for the front end design of the ATI web portal.











Forms & Reports

Request Form

A brief review of the request form file folder shows that most requests do not follow the request form format described in the ATI Act. Instead the majority are from emails and letters. 

ATI Act Form Format

The following exhibit is an example of an application in the Act Format.



An Email Example

Note: generally email and mail requests are more complex. We will need to design an entry form that will accommodate this type of requests.





Letter Request



Complaints & Appeals for Action

Delays in response

Many complaints pertain to delays in response, reason unknown, others are poor service from the public officers responsible. Examples are shown below:



Sample FOIA Input Form Requirements

You can compare the input form information your Act requests in comparision to the U.S. Freedom of Information request forms below to determine if there are any fields that you may want to add or remove as a result.
























Comments

Post a Comment