Requirements, Constraints, and Criteria
Requirements, constraints and criteria are a critical component of a needs assessment, and will be used by yourself and others involved in the project to guide design decisions throughout the project’s life. All three should be measurable.
Requirements
Requirement | Success Metric |
|---|---|
GUI must display and update data as required | Includes longitude, latitude, motor output, altitude, dictionary, etc. |
Run on any windows computer | requirements.text with all the dependencies |
Proper Video Feed | Has a clear video feed which updates properly on real time to help pilot control the aircraft |
Different data update speed depending on the data type | Multiple QThread for the data update |
Constraints
Constraints are design specifications that need impose strict limits on the designed solution. If a constraint is ignored, the design solution is also incomplete.
Constraint | Description |
|---|---|
Map Update Time | Map will only update after every five seconds |
Low latency | <100 ms in latency |
Can only Run on specific OS | Can only run on MacOS, and Windows |
Criteria / Objectives
If there is a specification that needs to be communicated but is not a requirement or a constraint it is likely to be a criterion. A criterion communicates important design goals that are impossible to capture in requirements and constraints.
Criteria/Objectives | Description |
|---|---|
Displaying Data | Data should be displayed and conveyed to the pilot in a way that is easy to comprehend (should not be displayed too quickly) |
Overlayed widgets | Datas such as directions, yaw should be displayed through widgets overlaying the video feed. |
User Testing Plan
Scenario 1: Using Mock Data/RFDs to Mimic “Flying Environment”
Overall Description: In this testing plan the overall goal will be seeing whether or not all the systems/components of the GUI work properly together. This will be done by using either the RFDs or Mock Data to simulate changes in the data to mimic an actual “flying environment”.
Expected Steps (With Mock Data or RFDs)
Switch to the appropriate branch in the IMACS code (in this case it would be the randomParse branch). If using RFDs, hook both modules up to your computer using the appropriate configurations.
Edit variables/classes with regards to what is being tested
Ex. if testing motor output readings, the appropriate variables must be edited in order to get a reading
Observe the readings carefully. If the data is changing and is being displayed properly. Ensure that the data is being displayed at an appropriate rate that is readable for the pilots. Also take into consideration whether or not there are functional problems with the GUI (ex. lag). \
Allow the potential pilots to observe the system in its entirety and interact with it. Take note of their opinion on various components/systems
Ensure that observations have met the specified requirements listed earlier in the document
Potential Bias: Some potential bias could be the definition of whether or not the data is being displayed at an “appropriate rate”. This could be a different measurement for different people. Therefore, I think it is best to let the pilot decide (Anthony/Megan) which display rate is the best for them.
Scenario 2: Using a Testing Platform (Ex. Houston).
Overall Description: This would essentially be testing the same things as the previous scenario, except it would measure in flight data from Houston (ex. altitude, latitude, motor output etc. ). This could be effective by giving the pilots actual flight experience with the GUI. However, the downside is that it would take a lot of time to actually prep the aircraft for operation.
My Recommendation: I would suggest going with scenario 1. I believe that the most important thing is to test all the components of the GUI, and to see whether or not data readings are being received properly. Scenario 1 does all of these things properly. Scenario 2, could also work, but there is more work and time involved which is not ideal.