SPIKE: Data flow diagramming

[aQuib]

Background This story is about researching the user needs regarding report generation with TIM data. We want to understand who needs access to the data and for what user, what are the permit data necessities for downstream reporting, what data types for firewood permitting will be moved to FPFS, what are the frequency and schedules of reports, and which admin users require access to data (and whether data calls will be one way or bi-directional).

Acceptance criteria

• [x] We have documented relevant insights of TIM users reporting needs
• [x] We have documented third party integration needs wrt to data flow
• [x] Documentation is findable in the wiki

Tasks

• [x] Review service blueprint (TIM interactions)
• [x] Review proposed architecture diagram
• [x] Review sample reports and worksheets from TIM and reporting requirements doc
• [x] Draft research plan ~- [ ] Schedule interviews with 3-5 report generators and consumers~
• [x] Interview TIM admin users/SME ~- [ ] Write up topline~
• [x] Create a visual representation of a detailed, as-is information flow
• [x] Create a visual representation of a detailed, to-be information flow
• [x] Validate information flows with PO & PM
• [x] Revisit design hypotheses in research plan
• [x] Post to wiki

Definition of done

• [ ] Acceptance criteria met

[csstarling]

Looks good, we might want to consult an auditor of Frontliner. Frontliners will need to meet auditor requirements with reporting features.

[MelissaBraxton]

In chatting with Michelle and Chris, frontliners are only audited on tags and dollars that are tied to in-office sales, so needing to meet frontliner's auditing requirements is not a concern for online sales.

[csstarling]

For MVP we are not designing a frontliner reporting interface. Consider changing the title of this story so that we are not suggesting generating reports from TIM data.

[tram]

Changing the title in response to Chris’s comment.

Pulled notes from prior research that fulfills “Schedule interviews with 3-5 report generators and consumers” task. Will validate visualizations with SMEs.

Visualization to replace topline. Added as-is information flow to tasks.

[MelissaBraxton]

Relevant assumptions:

• No permittee data will be stored as part of the MVP--it will be exported in csv format that USFS staff with a need to know at pilot forests can access
• We are aiming to ask for information that frontliners need up-front via #109, but that info will not be stored in Open Forest until we have a SORN.
• To avoid potential security and privacy issues, we're aiming to have as minimal permittee info as possible be emailed and printed on the permit (#140) . Current understanding is that the min. info could be name (+transaction data, like permit ID and date of purchase), but we've heard of a desire for name+address, and possibly permittee ID # as well. While ultimately what get's printed on the permit depends on LEO needs and what the USFS privacy and security folks approve, our GSA privacy officer has advised that emailing a permit that contains as much as name + address + unique identifier could be allowed, provided that we are transparent to permittees re: how their info will be used.

@bboddiger - it would be good to reach out to Deb White to get her take on what permittee info would be allowable to email to permittees, in advance of us diving into the permit design (#140)

cc @aQuib , @tram , and @Rebekah-Hernandez

[aQuib]

Here is data flow digram

[tram]

Added permittee data for export.

[carlsonem]

@aQuib @tram Is this now complete?

[aQuib]

Yes