- Requirements ===============
Login page:
-Username and password fields accept alphanumerical characters and soymbols.
-Username and password have to match in order to get to the next page.
Sign up page:
-Username field accepts alphanumerical characters and symbols, and it has to be at least 2 characters long.
-Password and Repeat password fields accept also alphanumerical characters and symbols and theyhave to match.
-E-mail field accepts alphanumerical characters and some symbols, has to have a @-sign after which comes the domain name.
-First name and Last name only accept alphabetical characters.
-Year of birth accepts only numerical values (DD-MM-YYYY).
-Study group is an optional field, and it accepts numerical and alphabetical characters.
-Teacher/Student is also optional and it has radio buttons.
Main page:
-Redirects the user to several pages by clicking the icon.
Map screen:
-Allows user to zoom in and out in the map, and change the view either by clicking the buttons "+"/"-" or by controlling the map with fingers.
People list page:
-By clicking red or green circles, the user defines weather the person shown in the list is a friend or foe.
Search page:
-Field accepts only alphabetical characters.
Settings page:
-Controlled by click
Edit account page:
-First name and last name are unchangeable after sign up. Check the other fields from sign up page.
Plan route page:
-Start point and end point accept only alphabetical characters.
To make the system easy to use, the mock-ups and design must work as expected, which means that the system feels natural to use. All of the buttons are where expected, main page is easy to find, and all is all we have to design the system in a way that is used in other softwares too, so even if the user is using it for the first time, it's easy to assume where different options and functions can be found. So in addition to the standard placing of the elements the colors are used as guidelines, separating for example friends with green and foes with red color.
Some possible system failures: The network connection is not available, the phone runs out of battery or the application crashes
The network connection is not available: If the user doesn't have network from the start, he can open the application, edit account information and go through his lists of friends and foes, but he cannot plan a route or get locations. If he gets the network connection, his friends and foes appear to the map, and he can use the whole application, without needing to start it again. If the user has the connection, but looses it in the middle of using the application, the user can still see the friends, foes and himself going around in the school area, but cannot see the statuses changing.
The battery runs out: When the battery runs out, unsaved data is lost, including locations and a halfway-through routes. But otherwise the application should work normally when started again and not give an error.
Application crashes: If the application crashes, the consequence is teh same as if when the phone shuts down during using the application.
The application is downloaded to every users phone, so it shouldn't crash because of too many users at the same time. What might cause some problems, is the poor working of the wireless access points in the school area. If the access points don't work well, it affects the application also, and might cause a "bottleneck-effect", which means that the requests get lined-up, and are handled in chronological order. If the request is taking too long, it is aborted, then the user has to resend the request.
In our software, we should definitely keep track on bugs per line of code, code coverage, number of lines of code and program execution time, load time and size.
Our code coverage would be high, because we will have to do a lot of testing, to prevent bugs from appearing in the final version and updates. When executing the test suite, we calculate the code coverage with the percent of program subroutines and the percent of program statements. We have to try to find all of the bugs, so that the application doesn't crash, freeze, give errors or allow a user to obtain unauthorized privileges.
Source lines of code (SLOC) then is used to estimate the programming productivity and maintainability. The lines also reduce the size of the code, and so affect the program execution and load time.