User Stories
- As a researcher, I want to set the motor/piston settings to be configurable for each motor so I create the most customizable waves.
- As a researcher, I want to access a feature to figure out why the pistons are out of sync.
- As a researcher, I want to be able to save settings properly so the motors will run at the rate I select.
- As a researcher, I would like all the motors I select to run with no lag or pistons being skipped.
Requirements
FUNCTIONAL REQUIREMENTS:
- Definite:
- Regular Input – when starting the GUI, there is an option to run the pistons with manual parameter values. Once the user manually inputs these values and presses the start button, the pistons should move as intended.
- Presets – pre-determined set of parameters that control the pistons. There is a folder containing existing presets that can be uploaded to the GUI. This folder can be modified to update, erase and create new presets. If the user runs the pistons via preset option, the pistons should follow the performance indicated by this preset.
- Curve IDs – there is also an option for the user to input a Curve ID, which corresponds to a set of data that indicates where pistons should be at different points in time. If a user inputs a curve ID and runs the program, pistons should run accordingly, and any preset or value written should be overridden.
- Feedback – this software allows the user to select an option to receive feedback in order to analyze where the pistons were at different points in time after running the program. If the user selects this option and runs the program, it should provide a .csv file with the data.
- Perhaps:
- Data model to analyze the positions of pistons over time – despite software working correctly and actually setting the parameters for the motors to run accordingly, each piston operates through a different length and altitude in the water tanks. This generates different resistances and causes pistons to move at different speeds, ultimately de-synchronizing. The implementation of a data model would allow the user to receive output analyzing if and when different pistons were not synchronized.
- Database to store all runs for analysis – once the researcher sets the values and starts the pistons, they can view the current data in the feedback page. By creating a database, the researcher can view past and current piston runs’ data. If the researcher starts a new run, results should be added to the database with past runs.
- Improbable:
- Implement a working model that synchronizes pistons – as mentioned previously, pistons are not currently working in a synchronized manner. With a data model, a general rule for each piston could be generated such that whatever parameters inputed by the user is modified behind the scenes and ultimately makes the pistons work in synchronicity. Ultimately, if the researcher enters all these values, they should be able to see the pistons moving at the same time.
NON-FUNCTIONAL REQUIREMENTS:
- Definite:
- User interface doesn’t have to be updated for each preset (usability & interface) – with respect to the usability of our interface, it should be working properly when inputting presets. There should be no need to re-input the preset’s parameter values after loading the preset. In fact, that invalidates the whole preset feature, so this is a definite requirement.
- Program doesn’t get stuck (performance & usability) – performance and usability is crucial in our software in order to avoid it getting stuck while the motors are running. It takes a long time to set everything up, and there are existing complaints about the GUI randomly breaking. Another non-functional requirement involves our new version to function properly and avoid this.
- Results/feedback is easily accessed every time and are not lost (reliability) – at the moment, feedback is not automatically saved (the option must be selected). Apart from that, there is no way to access the results of previous runs. In order to ensure reliability, results should be automatically saved in a folder for every run.
- Efficiency in the loading of data – once again, setting the hardware up and filling tanks with water takes time and resources. In terms of performance, the software must not incorrectly load parameters and should not crash randomly. This could result in a waste of time for professors and possibly affect the research project results.