Requirements
Final Requirements
Here are final requirements that we have devised from our project course and multiple meetings with the clients.
| ID | Requirement | Functional? | Priority |
|---|---|---|---|
| R01 | The server must use data sets with different update times (e.g. in real time, hourly, monthly) | Functional | Must |
| R02 | The smartwatch must display the pollution data | Functional | Must |
| R03 | The smartwatch must have an intuitive and clear UI using visusalisations that are widely recognisable | Non-Functional | Must |
| R04 | The smartwatch must have a scalar data view | Non-Functional | Must |
| R05 | The smartwatch must have a detailed data view | Non-Functional | Must |
| R06 | The smartwatch must interact with the smartphone app | Functional | Must |
| R07 | The smartphone must send requests to the API | Functional | Must |
| R08 | The smartphone must receive data from the API | Functional | Must |
| R09 | The smartphone must request new data when location changes | Functional | Must |
| R10 | The smartphone must be able to send notifications to the smartwatch on a location change | Functional | Must |
| R11 | Should have our own database in which all data is consolidated and stored | Functional | Should |
| R12 | Should have a synchronous connection to database | Functional | Should |
| R13 | Should have an asynchronous connection to database | Functional | Should |
| R14 | The app should store the last set of data received offline | Functional | Should |
| R15 | Should be able to update data upon demand | Functional | Should |
| R16 | The database should have clearly defined zones of the city | Functional | Should |
| R17 | The backend API shall include traffic data in London and the smartwatch app should visualise those data | Functional | Could |
| R18 | The smartwatch app shall allow user to search for pollution data of a particular location by using voice command | Functional | Could |
| R19 | The smartphone app shall have an better UI that provides detailed visualisations of pollution data | Non-Functional | Could |
| R20 | The smartphone app shall include information about the effects on health of each pollutants | Non-Functional | Could |
| R21 | The smartphone app shall cache pollution data when the device is connected to wifi to reduce data usage | Non-Functional | Could |
| R22 | The project would extend to other cities | Functional | Would |
| R23 | The API would include more data sources | Functional | Would |
| R24 | The database would have developed API allowing others to use it | Functional | Would |
Initial Requirements - MoSCoW
Based on initial meetings with our client, we identified some simple MoSCoW requirements that were requested for our system.
Must
- Use 3 pollution data sets updated at different rates ie live, daily, yearly
- Display data visually on a smartwatch
- Have a general view and a detailed view for each type of data
- Interact with an android app
- Must update as the user moves round the city and periodically or when the user requests a refresh
- Have a clear simple UI
Should
- Have our own database to consolidate all other data sources into
- Send notifications to users based on air quality and their quality preferences
- Have synchronous and asynchronous connection to database
- Store the last set of data offline in the app
- Have clearly defined zones for the city
Could
- Include social data eg twitter posts or facebook etc.
- Include traffic data
- Allow user to select which information they want to display
Would
- Extend for use in other cities
- Extend to a fully fledged android or web app for visualisations as well
- Develop api for our database so others can use the data we have consolidated
- Expand the number of data sources we are using to
Use Cases
Use Case 1: Recieving Data Updates
| Name | StartReceivingDataUpdates |
|---|---|
| ID | UC1 |
| Brief Description | The user starts the app to constantly receive air quality data based on location change |
| Primary Actor | User |
| Secondary Actor | None |
| Preconditions | The phone is connected to the Internet |
| Main Flow |
1) The user opens the app on the smartphone. 2) The app starts the data service that runs in the background and constantly send data to the smartwatch |
| Post Conditions | The data service is started |
| Alterative Flows | None |
User Case 2: User Checking Air Quality
| Name | CheckAirQuality |
|---|---|
| ID | UC2 |
| Brief Description | The user uses the app to check the air quality of current location |
| Primary Actor | User |
| Secondary Actor | None |
| Preconditions | The phone is connected to the Internet and the data service is running |
| Main Flow |
1) The app displays the main menu which contains for icons on the smartwatch 2) The user clicks the Air icon 3) The smartwatch displays the data for each pollutants in the form of coloured blocks |
| Post Conditions | None |
| Alterative Flows | None |
Use Case 3: Checking Raw Values
| Name | CheckAirQualityRawData |
|---|---|
| ID | UC3 |
| Brief Description | The user uses the app to check the raw values of different air pollutants in current location |
| Primary Actor | User |
| Secondary Actor | None |
| Preconditions | The phone is connected to the Internet and the data service is running |
| Main Flow |
1) The app displays the main menu which contains for icons on the smartwatch 2) The user clicks the Air icon 3) The smartwatch displays the data for each pollutants in the form of coloured blocks 4) The user clicks the top bar of the current view 5) The system displays the raw value for each air pollutant |
| Post Conditions | None |
| Alterative Flows | None |
Use Case 4: Halting Data Update Retrieval
| Name | StopReceivingDataUpdate |
|---|---|
| ID | UC4 |
| Brief Description | The user decides to stop receiving data updates |
| Primary Actor | User |
| Secondary Actor | None |
| Preconditions | The phone is connected to the Internet and the data service is running |
| Main Flow |
1) The user opens the app on the smartphone 2) The user clicks the stop update button 3) The app stops the data service that has been running in the background |
| Post Conditions | The data service is stopped and the smartwatch will no longer receive data from the phone |
| Alterative Flows | None |
Use Case 5: Requesting API Data
| Name | RequestDataFromAPI |
|---|---|
| ID | UC5 |
| Brief Description | The smartphone app requests air quality data from the backend API |
| Primary Actor | Smartphone app |
| Secondary Actor | None |
| Preconditions | The phone is connected to the Internet and the data service is running |
| Main Flow |
1) The app detects a location change 2) The app make a request with the current coordinates as query parameters to the API 3) The API returns a json array that contains all the data with the nearest one as the first element |
| Post Conditions | None |
| Alterative Flows | None |