[L] PRDT: Data/Business Rules Exploration

[meyerdarcie]

Description:

Before prototyping, we need to explore and understand backcountry business rules and booking data.

This ticket is to gain access to and look at backcountry business rules and data, and create a workflow of the rules.

Acceptance Criteria:

• [x] Attend tutorial from reservation services on backcountry admin/field system (Jun 25 1:30-2:30)
• [x] Dev team access to field system (In progress - Diana working with Jessica M)
• [ ] Review backcountry business rules and details spreadsheet --> Create flow diagram. https://bcgov.sharepoint.com/:x:/r/teams/08548/Shared%20Documents/General/1.%20Project%20Documentation/4.%20Parks%20%26%20Rec%20Digital%20Transformation%20Project/Backcountry/Backcountry%20details.xlsx?d=w73f7a217e0c849ca844275d30d332726&csf=1&web=1&e=iW6jCQ
• [ ] Document and gaps or concerns with implementing business rules - clarify what is the purpose of each rule? Review KPIs.

Development Checklist:

• [ ] ...
• [ ] ...
• [ ] ...

Dependencies

• Blocked by
• Blocking

Relevant documentation as reference

Definition of Ready

• [ ] Acceptance criteria are included
• [ ] Wireframes are included (if applicable)
• [ ] Design / Solution is accepted by Product Owner (if applicable)
• [ ] Dependencies are identified (technical, business, regulatory/policy)
• [ ] Story has been estimated (under 13 pts)

Definition of Done

• In progress:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] UI meets accessibility requirements
  • [ ] Unit tests are written
  • [ ] Work is traceable in GitHub
  • [ ] PR linked to ticket number
  • [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
• Code review:
  • [ ] Code is peer reviewed and has passed CI/CD tests
• QA:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Code is potentially shippable to the production environment
  • [ ] Functional features have been tested and passed by QA
  • [ ] UI components tested by designer
  • [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
• PO Review:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Reviewed and approved by Product Owner

Notes

Notes from June 4 Refinement:

• Exploring data = bcgov/parks-data-register#1
• For search, you need a minimum set of things that you need to collect from a user that you can then use to allocate the data/inventory we have
• Eg: if you want to book a backcountry reservation (tent pad, specific area, specific park, spec # of nights), we need to know all of that info for ever sub area for everything that would be in the system. eg: how many parks are contained within the bc reservation, what days of the year can you do that.
• Jess M: Extracts on LAN - site details for each park. All in excel sheet, columns correlate to what we currently use. Pulled last in January, have been updated since (via date modified).

• Business details - bc res services would have to gather that info for us. They have it on a confluence for camis. We would need to get together.

• We can get access to admin side, but API can't be shared.

• City Wide has a lot of data in that system

• Details on reservations, parks site, city wide, if one thing gets updated, how do we make sure it gets updated across all the things?

• Can we be the authoritative source of the data?

• Who are all the consumers of this data? We get media requests, other sites scrape the data to create their own notify systems for example.

• Diana to send Jessica M list for folks to get access to the backend of their field system (Camis admin). that way we can pull reports as we need it.

• Question: what are the things that absolutely cannot budge. vs. we can change the policy?? Darcie - could condense the board a bit more with the rules imposed on us. What are the constraints we are working within? eg: Legislated fees won't change during this prototyping phase.

• Nicole: we can use those tables that highlight each of the options and notes about them - mark in the squares what's not impossible but hard to change. --> https://app.mural.co/t/dds5274/m/dds5274/1714757875796/647a7ad4c84bb7284451808a72517d80d8c0fdf6?wid=0-1715965832558

  • (findings will be documented in bcgov/reserve-rec-public#11 policy inventory)
  • Why generate each report? What is the purpose of them?

[Dianadec]

Refinement notes:

• Business rules review: create flow diagram - the whole branching methodology - a whole chart that needs to be created (Added to the AC)
• Need to place this AC in a new ticket: (UPDATE: DONE: https://github.com/bcgov/reserve-rec-public/issues/1)
• [ ] Review Camis attendance reports: (https://bcgov.sharepoint.com/:x:/r/teams/031072/_layouts/15/Doc.aspx?sourcedoc=%7BC1BE4FA2-C24C-4A38-9B82-94E5A0D46DAF%7D&file=BackcountryReg-StatReport-Daily-Mar-2022-Mar-2024-AllAccessPts.xlsx&wdOrigin=TEAMS-MAGLEV.p2p_ns.rwc&action=default&mobileredirect=true
• [ ] Document data gaps, or missing data required to move forward (if any)
• [ ] Document future storage possibilities/ideas (if any)

[Dianadec]

I'll add links directly to the related mural boards to the sharepoint folder @cameronpettit

[cameronpettit]

Working on booking flows here if anyone wishes to take a look