...
To facilitate information sharing while ensuring each contributors true identity, we will establish, publicize, share, and use a standardized account structuredefinition.
Persona’s
Note: personas are in process of being built. Once in place, the links will be provided to those personas.
...
There is no established standardized account structure definition and interaction for SaaS applications in general or for GRC solutions in particular. Nor does UC publish or use a standardized account mechanism for any of its existing applications including Mapper, Dictionary, or the UCF. With no agreed upon standardized account structure definition and interaction, it makes it unnecessarily complicated 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.
...
Establishing and utilizing a standardized account structure definition and interaction will
...
:
Prove Unified Compliance as a thought leader in the GRC space
Make it easier for third-party applications to integrate with UC applications and will meet or beat third-party trust requirements as to establishing trust
Set a standard for all future UC applications on how to establish trust in order to facilitate contribution
...
There is no direct monetization component tied to Standardized Accounts; however, content contributed by third parties to the public federated database and federated dictionary will need to be attributed to the person or organization that contributed the content for potential monetization. In addition, data usage will need to be tracked, specifically to users and accounts for billing purposes. Standardized accounts are in an integral part of establishing who will be charged for usage and given credit for contribution.
...
It assumed that third-party applications will have similar enough account requirements that they will be able to setup accounts (primarily using organizationorganizations, accounts, and users) that they can integrate directly with UC applications once in place.
Risk One risk is that the establishment of organizations, accounts, and users may create a confusing onboarding and login experience driving prospects and customers away. The onboarding and login user experience must be made easy yet thorough to establish trust.
Milestones and Phases
List the project milestones along with how that milestone can be successfully measured.
Number | Description | Success Measurement |
|---|---|---|
TBD | ||
Product Requirements
Use Cases
...
As 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 details that will perform tasks such as research researching terms and contributioncontributing content.
Rainy Day Scenarios
After I setup my organization, I realize I made some mistakes and want to change pretty much everything including the legal name, name, description, primary e-mail address, founded date, primary phone number, and primary address.
After I setup my organization, I realize I should have used a different domain and want to start over or swap out to a different domain. If I can’t change domains, then I need the existing organization to be deleted so that no one can mistakenly use it
After I setup my first account, I realize I made some mistakes and want to change pretty much everything including the name, primary phone number, and primary address
After I setup my user ID, I realize I made some mistakes and want to change pretty much everything including the first name, middle name, last name, and how I want to contribute.
After I setup my user details so that I can contribute content, I realize I made some mistakes and want to change pretty much everything including my name prefix, suffix, middle initial, phone number, address, social accounts., languages, and membership in groups, teams, and initiatives.
Requirements
Requirement | User Story | Importance | Jira Issue | Comments |
|---|---|---|---|---|
Organization | Reference to the GRCschema definition | |||
Ability to create and setup a new Organization with all required information as identified in the standardized account definition | ||||
Ability to update an existing organization including name, email address, and other fields identified in the | ||||
change org avatar name and color | ||||
Register for mapper and gain access to profile and email | ||||
RBAC for at least admins vs others | ||||
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 | ||||
Multiple user names | ||||
Make one name primary | ||||
Remove all names but one | ||||
Define aliases | ||||
remove all aliases | ||||
phone numbers | ||||
email addresses | ||||
social media addresses | ||||
street addresses | ||||
teams | ||||
roles | ||||
contributor gating / approval governance |
...
Process Flow Diagrams
...