... | ... | @@ -8,9 +8,35 @@ |
|
|
*
|
|
|
|
|
|
|
|
|
## Scope
|
|
|
*
|
|
|
|
|
|
## Scope (FURPS+) *****Need to add features & requirements that will NOT be checked*****
|
|
|
* Functionality (functional requirements)
|
|
|
* Users should be able to log in to their account (in the app)
|
|
|
* The user/member should be able to search for leagues and teams
|
|
|
* The user should be able to join a team
|
|
|
* The user should be able to see members on their team
|
|
|
* The user should be able to see and add scores for games played by their team
|
|
|
* Team owners should be able to accept user requests to join their team
|
|
|
* The user should be able to edit their info in the app
|
|
|
* Usability
|
|
|
* Our app should be easily downloadable, which we will ensure by publishing on the Google play store
|
|
|
* Our app should be easily navigate-able by an average university student (including both our stakeholders, which are university students), and intuitive enough so that a user can use the basic functionality of the app without reading a manual/instructions
|
|
|
* App layout should be consistent for the user (i.e. navigation menu placed at the same location on all pages, etc.)
|
|
|
* Reliability
|
|
|
* Our app should be available 24/7 with minimal downtime (ideally 0 seconds)
|
|
|
* Since our app relies on the main point of storage being a server (firebase database), our app will be affected if any outages occur on this server. However, we will try to also store data locally on the phone, so that the user can use the app without being connected to the server (and then the app auto-syncs when connected to the server).
|
|
|
* Performance
|
|
|
* The app should look and feel smooth in terms of loading data, rendering the UI, and displaying animations (i.e. switching between screens). The user should not be able to notice the time between frames in an animation.
|
|
|
* Our app should also load within 3 seconds max. if we compare this time to a website, it will be faster than 50% of the web and corresponds with the time that the average user leaves a website if it has not loaded yet (https://www.bluecorona.com/blog/how-fast-should-website-be/). We will aim for 1-2 seconds load time, but 3 seconds will be our max.
|
|
|
* Supportability
|
|
|
* Our product (the app) will be published on the Google Play Store. Releasing updates/revisions will also be published on the Google Play Store, which is how our users will be able to update the app.
|
|
|
* Our system is very maintainable, since we own (or have access to) all aspects of the app: Android Studio (which is where our app can be modified and features can be added), and Google firebase. Both of these things will be available and used by us even after the class is done this semester.
|
|
|
* Testing for this system will occur locally through Android Studio (unit tests by testing individual classes, and systems tests by using the Android emulator). Through the emulator, we will be able to test our app on a variety of phones and Android OS versions.
|
|
|
* Our app can also be easily modified (and features can be added), since all the source code can be edited on android Studio.
|
|
|
* "+" (design, implementation, interface, and physical constraints)
|
|
|
* Design Constraint: Since we are using firebase for database/cloud storage, our app needs to integrate this (and therefore only use the features available in firebase).
|
|
|
* Implementation Constraint: We are limited in construction of the app by our language, Java, which is the main language used for Android apps worldwide. Another limitation is using Android Studio which is the official/main IDE for android development.
|
|
|
* Interface Constraint: We self-imposed a restriction of programing for only Android 5.0 (lollipop) and up. This was selected because of our need to use modern functionality, while also supporting older phones. Developing an app for Android 5.0 and up satisfies 85% of the worldwide market (and larger in North America).
|
|
|
* Physical Constraint: One of our largest constraints is the size of a phone. We need to make an app that is usable in a relatively small format (and the various different sizes available for Android phones, which means our design/layout has to be adaptable). We also need to take into account the different shapes for Android phones available (i.e. notch vs no-notch, camera cutout, different aspect ratio, etc.).
|
|
|
|
|
|
## Quality Objective
|
|
|
*
|
... | ... | |