Difference between revisions of "Administer Permissions and Settings"
From AccountIT
(→Basic Flow) |
m |
||
| Line 29: | Line 29: | ||
| 5. || The Actor enters required information for selected feature and requests to save the changes || | | 5. || The Actor enters required information for selected feature and requests to save the changes || | ||
|- | |- | ||
| − | | 6. || The System saves the changes || | + | | 6. || The System saves the changes || |
|} | |} | ||
| Line 42: | Line 42: | ||
* Each distinct function in AccountIT must have own permissions settings enabling fine-grained control on access. Must be moved to general requirement | * Each distinct function in AccountIT must have own permissions settings enabling fine-grained control on access. Must be moved to general requirement | ||
* Temporary system failures must be handled in a common way. This must be moved general requirements | * Temporary system failures must be handled in a common way. This must be moved general requirements | ||
| + | * The work flow after completing the feature needs to be defined as part of UX design | ||
* Access to the "admin functionality" requires that some initial permissions are set during "initial company setup" (else nobody from that company can access AccountIT) | * Access to the "admin functionality" requires that some initial permissions are set during "initial company setup" (else nobody from that company can access AccountIT) | ||
* The support for multi-tenancy means that a System Admin only is administrating for the particular "company" for whom he is setup to administer. | * The support for multi-tenancy means that a System Admin only is administrating for the particular "company" for whom he is setup to administer. | ||
Latest revision as of 13:28, 17 August 2014
Overview
| Use Case Title | Administer Permissions and Settings |
|---|---|
| Project | |
| Short description | The UC is to provide functionality to manage use accounts, such that users can perform required tasks within AccountIT. |
| Actor - primary | System Administrator |
| Actor - secondary | |
| Pre-conditions | AccountIT is running and Actor has the required permissions to access the functionality. The Actor has selected this function in AccountIT. |
Basic Flow
| Id | Steps | Comments |
|---|---|---|
| 1. | The Actor selects a feature he wants to use | Examples of features are: "create user", "change user permissions", "delete user" |
| 2. | The System requests Actor to provide parameters for requested feature | E.g. if "change user permissions" is selected, parameter would be "select user" from existing list of users. |
| 3. | The Actor enters require parameters | |
| 4. | The System provides access to the selected feature | The feature is displayed with appropriate controls (such as lists, edit boxes, etc.) |
| 5. | The Actor enters required information for selected feature and requests to save the changes | |
| 6. | The System saves the changes |
Alternative Flows
- (after 1): User does not have permission to particular feature.
- (after 1): Feature temporarily not available
- (after 3): The entered parameter does not validate
- (after 5): The entered information does not validate
- (after 6): Saving information fails
Additional Comments
- Each distinct function in AccountIT must have own permissions settings enabling fine-grained control on access. Must be moved to general requirement
- Temporary system failures must be handled in a common way. This must be moved general requirements
- The work flow after completing the feature needs to be defined as part of UX design
- Access to the "admin functionality" requires that some initial permissions are set during "initial company setup" (else nobody from that company can access AccountIT)
- The support for multi-tenancy means that a System Admin only is administrating for the particular "company" for whom he is setup to administer.
Document History
| Date | Version | Description | User |
|---|---|---|---|
| 2014-08-16 | 0.1 | 1st draft | Arvinder Singh |
