These requirements are broken down into three main categories: functional requirements, performance requirements, and environmental constraints. The first of which are the functional requirements, the operations that our application can perform. These include being able to utilize the user's GPS location, or the ability to send and retrieve data relevant to the Madingley model that is then displayed by the application's UI. Next, we have the performance requirements, which are characteristics that aren’t functionally necessary. However, they are needed to ensure the application is up to industry standards and can execute its functions in an efficient and safe manner. For example, the speed of the application and its security. Lastly, we will cover the environmental constraints of our application. These are the constraints that have been put together by our team, mentor, and client for various reasons such as the platform compatibility, or previously built components that are to be built into the application. All of these requirements were put together through various meetings with our team, mentor and client. During the Fall 2020 semester, we further refined them through intensive research and discussions.
1) Data Storage
- The ability to store relative application and user data amongst a designated cloud system
2) Graphic User Interface (GUI)
- The application will be viewed in a coherent and easy to understand way.
- The main menu of the application allow the user to select from a handful of options to learn more
about the project, technologies used, and project sponsor(s)
- The application will provide for various biodiversity options that the user can check off, and will be
displayed by the simulation
3) Location access
- Access to the user’s GPS.
4) Data processing
- A cloud based data processing back end that can interact with both the stored data and the client side
application.
5) Visualization
- The ability to visualize the results of a given scenario in the form of heatmaps, graphs, and
informational tables
- The ability to tailor the visualization to predefined subgroups like “policy makers” and “general
public”.
6) Data Exportation
- The application will have the ability to export the results of a scenario in a raw (CSV) form as well
as collection of images representing tables and graphs generated from the scenario.
1) Global Access
- The end goal of this application is to be used around the world.
- Since the developers associated with this project are located solely in the United States, this
requirement cannot be tested, but it can be assumed based on documentation provided by AWS, the App
Store, and Play Store.
2) Responsiveness
- There should be little to no screen lag between application pages that do not rely on back-end
components.
- If a new page does rely on a back-end component there should not be a significant (10+ second) lag for
processing.
- If it is determined that the sequential variation of the code cannot be improved upon then the code
base will be parallelized to the best of its ability.
3) Security
- Although the user will not be storing or inputting any information that is considered sensitive, it is
important to consider the security of application to prevent malicious actors from hijacking sessions,
or feeding malicious packets into the end-user’s connection.
- In order to ensure the security of the end-user, steps will be taken to authenticate and limit the
traffic and protocols accepted by both the server and client sides.
4) Application Crashes
- Applications that crash or fail frequently have a high likelihood of losing users to its lack of
usability.
- In order to limit chances of crashes the application will only process content on a need by need
basis.
- If the number of crashes increases as the iterations increases then the application is flawed at a
very low level.
5) Language Options
- A stretch goal associated with this project involves the ability to support multiple languages.
1) Programming Language Constraints
- As a result of the selected SDK, and other system components, we have been limited to what programming
languages we will be able to use to develop our application.
2) Web and Mobile Application
- In order to reach the largest number of people with our application, the client has requested that
this application run on at least two mobile platforms as well as a web platform.
- Due to the hardware limitations and dependencies of both mobile and web based components, the amount
of computation done on an end user’s device must be limited to the capabilities and components that are
built-in to the device.
A more detailed description of our requirements can be found here:
The initial concept for this project created by the team sponsor: