The Problem Space
In this step of the design process, you need to define the problem space. The problem space is the system that encompasses and surrounds your defined solution. As you define the problem space you should be thinking about questions including, but not limited to:
What are we trying to achieve?
Why are we trying to achieve it?
Who does it affect?
What other systems will be affected by the designed solution?
What effects will the designed solution have on other systems?
In order to be as effective as possible defining the problem space you should:
Clearly outline the problem that is being solved, and
Identify the users in the problem space (including secondary and tertiary users).
Primary users directly interact with the designed solution
Secondary users indirectly use the designed solution
Tertiary users are affected by the designed solution
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
Requirements are design specifications that need to be met in order to consider the design complete. If a requirement is not met, the designed solution is incomplete.
...
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.e.g. - The sensor must not take longer than 2ms to provide a reading to after a request is made
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.
e.g. - The ground station’s aircraft visualizations should be easy to understand
Developing the Needs Assessment
Throughout your development of the needs assessment, you should be careful to ensure that you are including all users in the problem space in the process. This could be directly asking them for requirements or performing interviews to understand the reasoning for their decisions and desires.
You should also take care to record as much information as possible as you develop the needs assessment. This includes your assumptions as you begin, research you do, and the requirements you develop.
When you have completed the needs assessment, be sure to summarize the problem so that it can be easily communicated to others as they become involved in the project.
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, then it maybe be considered a successful test. 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)
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 the,
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