...
People share information via e-mail, text, chat, phone calls or other applications. Once trust is establishedbetween 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 The system trust factor is similar to people where if systems want to talk with each other and to 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.
...
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 …There is no established standardized account structure for SaaS applications in general or for GRC solutions in particular. Nor does UC publish or use and standardized account structure for any of its existing applications including Mapper, Dictionary, or the UCF.
With no agreed upon standardized account structure, it makes it difficult for systems and applications to easily communicate and share information with one another.
In particular, third-party partner applications like AuditBoard and ServiceNow have limited direct integration with UCF.
Benefits
Establishing and utilizing a standardized account structure shows UC a thought leader in the GRC space
Makes it easier for third-party applications to integrate with UC applications and meets or beats their requirements as to establishing trust.
Sets a standard for all future UC applications on how to establish trust to facilitate contribution.
Subscription / Pricing / Billing Impacts
There is no direct monetization component tied to Standardized Accounts; however, content contributed by third parties to the public federated database will need to be attributed to the person or organization that contributed the content and data usage will need to be tracked specifically to accounts. Standardized accounts are in integral part of establishing who will be charged and given credit for contribution.
Beta and Early Access
Alpha and Beta access must be made available to selected members of the UC mapping team as they are actively using existing UC applications. Testers can validate both the API Gateway as well as the Mapper / UC 2.0 application.
Partners such as AuditBoard and Service Now might be good candidates to test with their applications, however, until content is made available, the value for establishing trust with no actual sharing is minimal.
Risks and Assumptions
It assumed that third-party applications will have similar enough account requirements that they will be able to setup accounts (primarily using organization, accounts, and users) that they can integrate directly with UC applications once in place.
The user experience must be made easy to use else it could get very confusing as to why organizations, accounts, and users are all needed.
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 successfulAs a content contributor I am able to quickly set up my organization that I work for, the account that I wish to start using the software with, and my specific user that will perform tasks such as research and contribution.
Rainy Day Scenarios
...
After I setup my organization,
Requirements
Requirement | User Story | Importance | Jira Issue | Comments |
|---|---|---|---|---|
| ||||
| colour | Red | title | HIGHAbility to create, update, and delete an organization||
Ability to create, update, and delete one or more accounts associated to an organization | ||||
Ability to create, update, and delete a user | ||||
Ability to associate / disassociate a user from an account | ||||
Ability to request / remove rights for a user to publish to the UC Federated Database |
Open Questions
List any open questions that come to mind throughout the lifecycle of this project
...