CMPE 451 Fall 2012 Group 6

advertisement

CMPE 451 Project Development in

Software Engineering, Fall 2012

Accessibility Violations

Final Document

10.01.2013

Index:

1.

Introduction

2.

Group Members

3.

Installation

4.

User Manual

4.1

Registration

4.2

Login

4.3

Profile Page

4.4

Add Report

3.1

Search for A Report

3.2

Report Detail Page

5.

System Manual

5.1 Use Case Diagram

5.2 Activity Diagram

5.3 Database Modeling Diagram

6. Use Case Scenarios

7. Requirements

7.1 Functional Requirements

7.1.1 Behavior of the System

7.1.2 Users Point of View

7.2 Non Functional Requirements

1.

Introduction

Everyone naturally has the right of accessibility to the places which all people can access.

However, some people with disabilities can not easily access whole places with different reason. In order to overcome this issue and make them use their natural right, we can report violations in our application with the help of socially responsible people who can contribute to our system over both web site and android application. We both can aware related authorities and make life of disabled people much more easier by reporting violations.

Hence, In our project, we created an accessibility violation tracking application that will support involving functions mentioned in the rest of the document in both user point of view and system functionalities in order to maintain natural rights of people.

2.

Group Members

The contributers of this project, as ordered by surnames, are:

- Murat Güvenç

- Aydan Inak

- Ülkü Buket Nazlıcan

- Semih Öztürk

- Mehmet Onur Serkan

- Hande Yentür

3. Installation

There is no required to install any other environments before any use in our web site. The user can access easily with the following link to our system; http://titan.cmpe.boun.edu.tr:8085/cmpe451Web/

The user can use our application in the android platform. The application can be accessed and downloaded via the following link http://cmpe352spring2012group6.googlecode.com/files/Accesibility%20Violations_v1.2.apk

4 User Manual

4.1

Registration

User has to be registered with the form located the right hand side of the main page in order to contribute to our system.

All fields in registration form should be filled out for successfull registration. In the scope of validation; it is controlled whether same username and e-mail exists or not.

4.2

Login

User can login to the system by entering their Username and Password on the top of the main page.

If user forgot the password, they should fill “Username” field and then click “Forgot

Password” button. The password will be sent to the e-mail address that the user recorded in registration.

4.3

Profile Page

After successful login, the user directed to the profile page which enables them to achieve following;

 Via “View my reports” button, user can view the list of own reports.

 Via “View my subscriptions” button, user can view the list of reports that is subscribed in order to get information about the status of involving reports by means of registered e-mail.

User can see the details of corresponding reports from summary accordions by clicking the name of the report.

In left navigation menu; o Via “Home Page”, user can be redirected to the main page of the website. o Via “Add Report”, user can be redirected to the form where they can add a report for a violation encountered. o Via “Search For A Report”, user can be redirected to the form where they can filter the reports in the system with specified fields and can see their details.

 Via “Logout” button, user can invalidate the session and redirected to the main page of website.

4.4

Add Report

The user who logged in, can add a report for a violation encountered by clicking “Add

Report” tab on the left navigation. In add report page;

User must choose a location on the map. o The map shows Rumelihisarüstü location by default. o By clicking “+” and “-” on the map or by mouse slide, the user can zoom in or zoom out on the map. o By typing a location to the auto complete search box above the map, the user can go to anywhere that Google Map provides. o In order to return to our base default location Rumelihisarüstü, the user should type “Boğaziçi Üniversitesi”

 User must fill the “Report Name” field too in order to pass the involving validation.

 User can add “Tags” by entering a related word in the “Tags” box optionally and enter. It is also allowed to add multiple tags to a specified report.

User should choose the type of violation from corresponding drop down list.

User should choose the status of the incident. o The status of the report is “Detected” by default. o Depending on what user observes about the involving report, they can choose a different status.

User can add a description about the violation / friendly location optionally.

User can add an image, video or audio optionally.

After filling the necessary fields and location on map, user now able to add the report by clicking on “Add Report” button.

4.5

Search for A Report

Both users and visitors are able to search for a report by clicking “Search For a

Report” tab on the left navigation from all pages in the website. In the search page;

The user can search according to location, possibly affected disability type, status of the report and/or tag.

The user can combine any of these 4 search criterions.

The user should specify at least one of all search options for a successful search.

Search results are listed according to the date added. And the result set can be ordered by date or rank by clicking corresponding table headers.

Search results are also shown on the map with different colored pins for changing status of filtered reports as following; o Red

Detected o Blue

In Progress o Yellow

Fixed o Green

Friendly Location

The user can go to the details of reports by clicking on Report Name in search results or clicking a pin on the map located right hand side of the page.

4.6

Report Detail Page

When the user selects a report in the search result list or on the map, they will be redirected to the detail page of the corresponding report. On this page as it can be seen in the screenshot below, the user are able to achieve following;

The user can see the details about the report and also its exact location on the map located in the right hand of the page.

 The user who logged in to the system can do followings by clicking “Submit

Changes” button after filling involving fields; o Adding tags by using Tag Box o Changing the status of the report o Adding comment about the report o Adding description to the report if it does not exists.

The user can rate the report to approve or deny it in the scope of validation of reports. o The user can rate up the report by clicking “Up” button if the report is beneficial according to the user. o The user can rate down the report by clicking “Down” button if the report is inappropriate and incorrect according to the user. o Report owners are not able to rate their own reports. o All registered users are not able to rate more than once for a specific report.

The user can also subscribe to or unsubscribe from the report with specified actions and details stated below. o The user can receive relevant information about the change in the status of report via registered e-mail if the “Subscribe” button clicked. o The user can unsubscribe from the report via clicking “Unsubscribe” button if the user were subscribed to the report before.

5 System Manual

In this section, design details of our system can be found which is extracted from our google code page.

5.1

Use Case Diagram

The main purpose of the use case diagram is to present what system functions are performed for which actor. It can be found the use case diagram of our Accessibility

Violations system below;

5.2

Activity Diagram

Activity diagram of our system is the graphical representation of workflows achieved by our Accessibility Violations system that can be found below. The diagram shows stepwise activities and actions including the overall flow of the control.

5.3

Database Modeling Diagram

The Database Diagram below states our current database model which is extracted from phpMyAdmin . Our main tables are Reports and Users. Other tables are connected to them and also each other to keep their relations stabilized in order to achieve our functional goals.

6.

Use Case Scenarios

Here it can be found some experiences and feedbacks of dedicated users. Our detailed functional tests can be found with the name of “Tests” in the scope of our deployment package from CD.

7.

Requirements

7.1 Functional Requirements

7.1.1 Behaviour of the System

1.

System shall provide sign-up and sign-in functionalities.

1.1.

There shall be control for mail verification.

1.2.

There shall be e-mail service for forgotten password.

2.

System shall provide search property for reports.

2.1.

Search shall be done according to violation type and report tag.

2.2.

Location search shall be done by using google maps auto-complete search option.

3.

System shall provide a map of violations and friendly locations.

3.1.

Friendly locations should be shown on map as green pin.

3.2.

Violations should be shown on map as red pin.

3.3.

System shall provide search property for map.

3.4.

Map should be filtered according to disabilities.

4.

There should be a “how it works” section which includes information about how to use the application.

4.1.

Help messages for users should appear based on the user’s request.

5.

Every registered user should have a score.

5.1.

The score of user should be increased in every correct report.

5.2.

The score of user should be decreased in every false report.

6.

Wrong reports should be able to be reportable.

6.1.

Admin shall warn the users who reports wrong violation via e-mail.

6.2.

After 5 wrong reports, admin should ban the user who reports wrong violation.

7.

System should provide a notification system.

7.1

Subscriptions can be achieved by using existing reports.

7.2.

User should be able to subscribe a violation. Notification system should inform users about changing status of violation in the list via e-mail.

7.3.

User should be able to subscribe a location. Notification system should inform users about a new report in this location via e-mail.

8.

Admin shall periodically report permanent violations to related authorities.

9 The system should collect reports by violation (obstacle) type. User can not decide if it is a problem for blind or deaf. They should only able to state what the problem is.

7.1.2 Users Point of View

1.

Users shall be able to report a violation.

1.1.

There shall be a map where violation is tagged.

1.2.

User shall be able to add a location for violation.

1.3.

Users shall be able to add a description in detail to their report.

1.3.1.

Users shall be able to add status which indicates the current situation of the violation like

“in progress” or “completed”.

1.4.

Users shall be able to upload images and videos.

1.5.

Users should be able to provide voice recordings of the violations for blind people.

1.6.

The date and the time of violations shall be reported also in terms of reliability. (For instance, a new report will be more reliable than an older one.)

1.7.

Violation type shall be chosen. (i.e; broken traffic lamp or inappropriate cavity )

2.

Users shall view a violation.

2.1.

Users shall be able to search a particular violation via entering any of type and location.

2.2.

Users shall be able to see the violations in the order sorted by date or rate.

2.3.

Users shall be able to see the summary of all violations.

2.4.

Users should be able to see violations on map and filter according to their disability.

3.

Users shall be able to comment on violations.

4.

Users should be able to rate violations up/down to increase/decrease the credibility of that report.

5.

Users should edit a violation report.

5.1.

Users should be able to update state of violation (nothing, changed-in, progress-fixed) to make application up-to-date.

6.

Guest users shall be able to view the report.

7.2 Non-Functional Requirements

1.

Usability

1.1.

Our application shall be user friendly which means appropriate to ISO/TR 16982:2002 and ISO

9241 standards.

1.2.

Web pages shall be simple and complexities shall be avoided.

1.3.

The language of application should be understandable and should not cause ambiguity and perfectly appropriate to the grammar of used language.

1.4.

Interface of application shall be simple and easy to use.

2.

Security and reliability

2.1.

System should be able to detect and deal with users who abuse the system.

2.2.

Users private information should be protected.

3.

Availability

3.1.

The webpage should support with internet explorer,google chrome, mozilla firefox.

3.2.

The application should support mobile interaction in android.

4.

Fast access

4.1.

User should be able to access violation reports in max 4-5 sec.

Download