Story: Clarify CAN Attribute Names

[jonnalley]

User Story

_As an OPRE staff member, I want to acquire more clarity or an explanation on an attribute name or heading when viewing a CAN so that I am not confused about the data presented and have a more pleasant user experience.

Acceptance Criteria

• [ ] Using some method in the user interface, a staff member is able to quickly and easily see an explanatory descriptor of an attribute name or "header" of data in an on-demand basis when viewing a CAN.

---

Tasks

• [ ] Procure definitions of each attribute based on prior Knowledge Transfer or user research already conducted
• [ ] Procure any definitions we don't yet have
• [ ] Make UI changes to accommodate showing the clarifying info for the user
• [ ] Swap out the web server for the backend from runserver to something else more production-apropos.

Definition of Done Checklist

• [ ] Usability validated
• [ ] Design QA passed
• [ ] OESA: Code refactored for clarity
• [ ] OESA: Dependency rules followed
• [ ] PR(s) have been merged to main with all the automated tests (load, quality, a11y, unit, etc..) and security scans that are a pre-requisite
• [ ] 90%+ Code coverage achieved
• [ ] Design/tech debt eliminated
• [ ] Build process updated
• [ ] Documentation updated or added
• [ ] Feature flags/toggles created

Additional Context & Resources

• A theme discovered in user research was a lack of universal awareness of certain labels and headings for data. A more descriptive explanation would be especially helpful for new OPRE staff or staff changing roles, for example.

[tdonaworth]

Curious why The backend component no longer uses runserver is part of this story? Look very independent.

[jonnalley]

@tdonaworth That AC/task was moved from 304 to a somewhat-arbitrary other story (this one) due to trying to narrow and de-bloat the slice more. I solicit and welcome any other suggestions

[jonnalley]

The MVP mural as well as the "OPS relationship diagrams" PDF/mural may be helpful here along