Page Comparison

Requirement specific constraints

Two versions of the modal:

1. Volume based

2. Depth based

Role based constraints

N/A

N/A

N/A

Does role determine what a user can see or do? Is this enforced uniformly across the front end and back end?

User preferences constraints

For both versions:

• All titles, subtitles, labels, units, inputs, etc. should be in the language of the user

• Clicking “Save” on the modal, appropriately saves “Total water usage” to LF-2800

Volume based modal:

• “Estimated flow rate” should be shown in system of measure (l / hr for metric, g / hr for imperial)

• “Total water usage” should be shown in system of measure (l for metric, g for imperial)

Depth based modal:

• “Estimated application depth” should be shown in system of measure (mm for metric, in for imperial)

• “Location size” should be shown in system of measure (ha for metric, ac for imperial)

• “Irrigated area” should be shown in system of measure (ha for metric, ac for imperial)

• “Total water usage” should be shown in system of measure (l for metric, g for imperial)

N/A; confirmed via database

Display units are appropriately persisted:

• “estimated_flow_rate” converted correctly to liters / min*

• “estimated_flow_rate_unit” matches what user selected via UI

• “estimated_duration” saved in minutes

• “estimated_duration_unit” matches what user selected via UI

• “Total water usage” should be shown in system of measure (l for metric, g for imperial)

• “application_depth” should be transformed to meters and appropriately saved

• “application_depth_unit” matches what user selected via UI

• “Estimated_water_usage” should be transformed to liters and appropriately saved

• “Estimated_water_usage_unit” matches what user selected via UI

Is this impacted by user or farm preferences such as language, system of measure, certification status?

Farm-level defaults / preferences

Volume based modal:

• “Default flow rate” is pre-populated if there is a default for the selected location

  • If a new location is selected by going backwards in the flow, this should update

Depth based modal:

• “Default application depth” is pre-populated if there is a default for the selected location

  • If a new location is selected by going backwards in the flow, this should update

N/A

Volume based modal:

• When “Default flow rate” is selected, we should…

  • Create a new location_default record with the “estimated_flow_rate” and “estimated_flow_rate_unit” populated if no location_default existed for that location

  • Update the location_default record with the new “estimated_flow_rate” and “estimated_flow_rate_unit” values if a location_default existed for that location

Depth based modal:

• When “Default application depth” is checked, we should…

  • Create a new location_default record with the “application_depth” and “application_depth_unit” populated if no location_default existed for that location

  • Update the location_default record with the new “application_depth” and “application_depth_unit” values if a location_default existed for that location

Numerical input constraints

Via UI

Volume based modal:

• “Estimated flow rate”

  • Decimal

  • 0 <= value <= 999,999.99

• “Estimated Duration”:

  • Decimal

  • 0 <= value <= 999,999.99

Depth based modal:

• “Estimated application depth”

  • Decimal

  • 0 <= value <= 999.99

• “% of location to be irrigated”

  • Decimal

  • 0 <= value <= 100.00

• “Total water usage”

  • Decimal

  • 0 <= value <= 999,999,999,999.99

Need to verify that the “Location size” is correct for the selected location.

Via POST on endpoint:

Volume based modal:

• “Estimated flow rate”

  • Decimal

  • 0 <= value <= 999,999.99

• “Estimated Duration”:

  • Decimal

  • 0 <= value <= 999,999.99

Depth based modal:

• “Estimated application depth”

  • Decimal

  • 0 <= value <= 999.99

• “% of location to be irrigated”

  • Decimal

  • 0 <= value <= 100.00

• “Total water usage”

  • Decimal

  • 0 <= value <= 999,999,999,999.99

Need to verify that the “Location size” is correct for the selected location.

Via direct database insert:

Volume based modal:

• “Estimated flow rate”

  • Decimal

  • 0 <= value <= 999,999.99

• “Estimated Duration”:

  • Decimal

  • 0 <= value <= 999,999.99

Depth based modal:

• “Estimated application depth”

  • Decimal

  • 0 <= value <= 999.99

• “% of location to be irrigated”

  • Decimal

  • 0 <= value <= 100.00

• “Total water usage”

  • Decimal

  • 0 <= value <= 999,999,999,999.99

Do we appropriately handle negative, very small, very large, or 0 as inputs?

Text input constraints

N/A

N/A

N/A

Do we appropriately handle blank, very small, and very large inputs? Is there a strict format (such as email) that must be followed?

Date based constraints

N/A

N/A

N/A

Are there logical restrictions on what dates can be input? Should a use be able to complete something in the future for example.

Date based assumptions

N/A

N/A

N/A

Are we making valid assumptions about what dates should be allowed?

Timezone driven interactions

N/A

N/A

N/A

If timezones play a role in the data, are they being displayed or converted appropriately?

Interaction / transitioning UI based constraints

N/A

N/A

N/A

Is the UI transitioning appropriately? Is the API providing da

Flow based constraints

Clicking “<“ and then reopening the modal displays previous inputs.

Clicking “Save” and then reopening displays previous inputs.

Changing location changes the location size displayed appropriately

Is state being preserved appropriately in a flow? If I go back and then forth, is it maintained? Is state invalidated when it should be?

Synchronous / asynchronous constraints

Is the user appropriately informed of transitions from synch to asynch and vice versa?

Is the interaction synchronous, asynchronous, or does it support both? Can you simulate both if so?

Time-out / low bandwidth constrains

Does the feature fail gracefully under no bandwidth / low bandwidth environments?

Data transformation correctness

Need to verify that the “Location size” is correct for the “Irrigated Area” is calculated appropriately.

Is the data persisted as expected post-transformation?

Are values appropriately updated when units change? Is it WYSIWYG?

Outcome correctness

Is it clear whether the outcome was a success of failure? Does it have the “right” visual treatment?

When inputting known inputs with expected outputs - do you get the results you expect? Have you tested several “cases” of this?

Switching farms

Does this feature respond well to switching farms (and returning)?

Notification constraints

Should a notification be marshalled based on this action?

Cascading effects

Are there logical places

Integration constrains

Do we need to ensure state is consistent between LiteFarm and the external service? What failure cases do we need to handle? How do we report back the outcome to the user or external service?