Overview
Background
People share information via e-mail, text, chat, phone calls or other applications. Once trust is established between two people (whether given lackadaisically or with caution) information sharing can begin after exchanging phone numbers, addresses, or profiles. Theoretically, in this one-on-one communication between two people, you know who you are sending data to and they know who they are receiving data from. However, if trust is given too freely without validation, one or both actors may or not be who they say they are.
In a world where data is shared between systems, the systems are the ones doing the sharing, not people.
This trust factor is similar to people where if systems want to talk with each other and share information, they must first trust each other and prove who they say they. As is the case with people, if trust is too easily given, a “bad actor” could cause irreparable damage.
To help protect systems from “bad actors” or mistakes, the trust factor is built into each communication and must contain the following two aspects:
Some form of security handshake
A system-based identifier for “who is who”
Objective
To help fulfill Unified Compliance’s mission statement to be THE authoritative platform for regulatory content, control frameworks, and policy guidance, one of the initiatives is to build products and functionality that extend the usage beyond professional lexicographers and glossarists to include many additional users to allow them to contribute to UC’s content repository.
To facilitate information sharing while ensuring each contributors true identity, we will establish, publicize, share, and use a standardized account structure.
Persona’s
Note: personas are in process of being built. Once in place, the links will be provided to those personas.
UC Mapper (linguist, English major, attention to detail …)
UC Mapper Approver (linguist, subject matter experts, …)
Partner Contributor (expert in their software and processes, not a linguist, busy with other tasks …)
Customer Contributor (institutional organization knowledge, domain expert, not a linguist, likely minimal compliance knowledge …)
Success Metrics
List project goals and the metrics we’ll use to judge success
Goal | Metric |
|---|---|
Establish and document a standardized account schema and publish it in grcschema.org | Review and attain sign-off from the GRC schema governing body |
Establish a set of APIs that utilize the standardized account schema | A UC-written application can interact with the API Gateway to establish trust and then share information |
Build a frontend application that utilizes the standardized account via a set of APIs | Mapper / UCH 2.0 can establish trust and share PlantUML data which updates the federated database and / or Compliance Dictionary can establish trust and share term definitions that update the compliance dictionary database or federated dictionary database (TBD) |
Current Challenges / Limitations
The “who is who” part is normally done in the form of an account structure. The challenge is, within the world of Compliance as Code, and all the various published schemas, there isn’t a standardized account structure.
Benefits
Highlight the main benefits the customer/user will gain by this product
Subscription / Pricing / Billing Impacts
Describe any financial impact this product will introduce (if any)
Beta and Early Access
Describe if beta customers and/or early access is essential for success. If betas are required, there could be a substantial recruitment process required which needs to be anticipated and planned for.
Risks and Assumptions
List any risk or assumptions you have about the users, technical constraints, business goals …
Milestones and Phases
List the project milestones along with how that milestone can be successfully measured.
Number | Description | Success Measurement |
|---|---|---|
Product Requirements
Describe the product requirements that will fulfill the underserved need(s) starting off with the use cases, then specific functionality
Use Cases
Happy Day Scenarios
This is the “happy path” that includes the beginning to end steps the customer/user takes to be successful.
Rainy Day Scenarios
Here is where you describe what to do when things go wrong (e.g., user closes the browser, API doesn’t return results …)
Requirements
Requirement | User Story | Importance | Jira Issue | Comments |
|---|---|---|---|---|
HIGH | ||||
Open Questions
List any open questions that come to mind throughout the lifecycle of this project
Question | Answer | Date Answered |
|---|---|---|
Out of Scope / Future Functionality
List the known features that are out of scope for this project or might be revisited at a later time.
As is case with the assumptions, it is important to list these out so that architects and engineers can plan accordingly for these later updates.
Impacted Product Components
If this project is a component to other areas or an update to an existing product, specifically call out where this product will interact with other areas.
User Interaction and Design
Link to mockups, prototypes, or screenshots related to the requirements.
Process Flow Diagrams
Links to user journeys, process flow, or other diagrams related to the requirements.
Guides
If there are UI components to this requirement, list the main areas where interactive user guides would be needed.
Additional References
List and link to any other reference sites, documents … that might be important to the reader.