Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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)

  1. 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.

  2. Edit variables/classes with regards to what is being tested

    1. Ex. if testing motor output readings, the appropriate variables must be edited in order to get a reading

  3. 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 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.

  • No labels