User Stories
Login and Authentication
U.S 1.01 - Github Authentication
As a user I want to be able to authenticate via Github authentication so that I can access the website
Story Point: 8
Acceptance Tests
- User should be able to open up a github authentication menu by clicking the github button
- User should be able to access the rest of the website if they enter a valid github authentication
- User should be returned to login screen if they enter an invalid github authentication
U.S 1.02 - Google Authentication
As a user I want to be able to authenticate via Google authentication so that I can access the website
Story Point: 5
Acceptance Tests
- User should be able to open up a google authentication menu by clicking the google button
- User should be able to access the rest of the website if they enter a valid google authentication
- User should be returned to login screen if they enter an invalid google authentication
U.S 1.03 - Username and Password Account Registration
As a user I want to be able to register an account via email and password so that I can access the website
Story Point: 5
Acceptance Tests
- User should receive a confirmation email when they register a new email and password
- User should have to verify their confirmation email before being able to use that email as a valid login
U.S 1.04 - Username and Password Account Login
As a user I want to be able to sign in via email and password so that I can access the website
Story Point: 3
Acceptance Tests
- User should be able to sign in with a verified email and password
- User should be directed to the rest of the website if they successfully login
- User should not be able to sign in with an unverified email and password
- User should be returned to login screen if they unsuccessfully login
U.S 1.05 - Account Saving
As a user, I want my information and Dev in a Box products to be saved to my account so that I can log off, log back in, and have my information/configurations preserved
Story Point: 13
Acceptance Tests
- If signing in with email and password, user should not have to register a new account
- Any payment information already provided should persist between sessions
- Any active subscriptions / Dev in a Box products should persist between sessions
- Any configuration changes should persist between sessions
- No information/payment information/subscriptions that were not provided/dictated by the user should be held
Organizations
U.S 2.01 - Automatic Default Organization
As a user I want to be the administrator of a default organization upon registration so that I can immediately set up my own environments
Story Point: 3
Acceptance Tests
- After registration, user should belong to an organization and should be the administrator of that organization
- The organization should have no other members
- The organization should not have any billing information come with it
- The user should not belong to any other organization
U.S 2.02 - Create New Organization
As a user, I want to be able to create a new organization of which I am the administrator so that I can start building a new set of environments for a different group of users
Story Point: 5
Acceptance Tests
- User should be able to open a form fill that takes parameters for an organization
- User should be able to create an organization after form is fully completed
- User should not be able to create an organization until form is fully completed
- The user’s created organization should be in correspondence with the form fill
- The user’s created organization should have no other members
- The user should be an administrator of the organization
U.S 2.03 - Switching Between Organizations
As a user, I want to be able to switch the dashboard between organizations so that I can view each organization’s environments separately
Story Point: 2
Acceptance Tests
- User should be able to see which organizations they belong to
- User should be able to select one organization at a time to view their environments
- User should have exactly one organization selected at all times
- User should only be able to select an organization that they belong to
- The default organization selected is the user’s personal default organization or a random organization (if personal is deleted)
U.S 2.04 - Inviting Members to Organization
As an administrator I want to be able to add other users as developers to the organization so that the people I want have access to the environments
Story Point: 8
Acceptance Tests
- User should be able to generate an invitation link to send to prospective developers
- Someone using that link should be brought to the website and automatically added to the organization after signing in
- This link should only add someone to the organization if they are the FIRST person to use this link
U.S 2.05 - Adjusting Roles within Organization
As an administrator I want to be able to view all members of organization and freely demote/promote others between non-member, developer, and administrator so that people can be given the appropriate access levels
Story Point: 8
Acceptance Tests
- User should be able to view all members of an organization in one concise panel
- User should be able to see which role each member has
- User should be able to change the roles of other members
- When changing the role, user should get a complete list of available roles
- User should be able to confirm their role modifications with a save button
- User’s changes should not be implemented if the save button is not pressed
U.S 2.06 - Preserving Last Administrator
As an administrator I want to be able to demote other administrators as long as they are not the last administrator so that an organization always has at least one administrator
Story Point: 1
Acceptance Tests
- The change role option should be invisible for the final administrator
U.S 2.07 - Disband Organization
As an administrator I want to be able to delete the organization so that I can close all instances and disband all members at once
Story Point: 5
Acceptance Tests
- User should see a delete option
- User should receive a confirmation message when trying to to delete an organization
- Organization should be deleted if confirmation message is accepted
- Organization should not be deleted if confirmation message is canceled out of
- Organization should not be deleted if >= 1 'Dev in a Box' instances exist
- All members of the organization should no longer see this organization
Managing Payments and new Subscriptions
U.S 3.01 - Payment Information Requirement for Organization
As a user, when I create a new organization, I want it to require a billing option and it should prompt me to input payment information so that I can setup instances without being prompted to pay
Story Point: 5
Acceptance Tests
- User should be prompted to supply payment information
- User should not be able to create environment until payment information is saved
U.S 3.02 - Payment Information Auto-Fill
As a user, when I am entering payment information, I want be given the option to auto-fill the payment information from other organizations of which I am an administrator so that I won’t have to enter the same information twice
Story Point: 3
Acceptance Tests
- User should be able to see a list of other payment information available to them and from which organization it is from
- User should not be able to payment information from organizations that they are not administrators of
- Users should be able to select and auto-fill from another organization that they are an administrator of
U.S 3.03 - Variable Charging
As a user I want a variable charge depending on amount of developers connecting to the Dev in a Box so that I am only charged for what I am using
Story Point: 2
Acceptance Tests
- User should pay variable amount based off formula for variable user amount
- User should not pay a flat rate subscription
- User cannot update without confirmation on the new subscription cost changes
- User should not be able to input a non-positive integer number of users when creating environment
- If amount of developers changes, user should be reimbursed for remainder of month at previous amount and a new billing cycle will commence
U.S 3.04 - Pay Via Credit Card
As a user I want to be able to pay with credit card so that I can deliver my payment
Story Point: 3
Acceptance Tests
- User should be able to pay with inputted credit card information
- User should get confirmation (from Stripe) that payment is successful
- User should get a warning that payment details are incorrect (delivered by Stripe)
- User should not be able to pay with debit or other payment methods
- User should not be able to pay with incorrect payment information
U.S 3.05 - Pay Via 3rd Party Methods
As a user I want to be able to pay with other third parties (Pay-Pal / Google Pay / Apple Pay) so that I can deliver my payment
Story Point: 5
Acceptance Tests
- User should be able to login to a third party software and pay for a subscription
- Environment should be created after user pays with a third party
U.S 3.06 - Editing Payment Information
As an administrator I want to be able to change the billing information so that I can charge a different account
Story Point: 2
Acceptance Tests
- User should see the same form fill as when creating a new organization for entering payment information
- New payment information should only be applied if user selects save and new payment information is verified
- User cannot change payment information to an unverified state
U.S 3.07 - View Payment Information Details
As an administrator I want to be able to viewa snippet of the currently configured billing information so that I am aware of the current payment method(s) attached to an organization.
Story Point: 2
Acceptance Tests
- Administrator should be able to view the type of card ('visa'/'mastercard') as well as the last 4 digits of the card currently attached to the organization.
- If an organization has no card attached, this view should be empty.
Managing Dev in a Box Products
U.S 4.01 - Create Dev in a Box
As an admin I want to be able to add another (or initial) environment any time so that I can start using another (or initial) Dev in a Box
Story Point: 5
Acceptance Tests
- When user wants to add a new instance, user should be brought to a form fill
- If a user exits the form fill they should be returned to the dashboard and no action occurs
- If a user does not fill in the form completely/correctly, the user should not be able to submit their new subscription
- If a user fills in the form completely they should be able to create a new instance
- If a user creates a new instance they should be returned to the dashboard and a new Dev in a Box will appear according to the specs defined in the form field
- If a user submits a new subscription, correct payment should be drawn from their credit card periodically
U.S 4.02 - View Dev in a Boxes
As a developer I want to be able to view existing Dev in a Box instances so that I know what I have and can see what I have access to
Story Point: 2
Acceptance Tests
- After login, user be able to see a list of all the environments they have access to
- User should be able to uniquely identify each environment
- User should not be able to see environments that they do not have access to
- User should not be able to see deleted environments
U.S 4.03 - Dashboard
As a developer I want to view all my subscriptions in a dashboard so that they’re nicely and compactly displayed to me
Story Point: 5
Acceptance Tests
- User should have a dashboard screen to see their environments
- All the users environments should be displayed on the dashboard
- Each environment should uniquely identifiable, no duplicates
- Users should only see their environments, not ones owned by other users
U.S 4.04 - Dev in a Box Details
As a developer I want to be able to view all the details of each Dev in a Box instance so that I know everything I need to know about my Dev in a Boxes
Story Point: 3
Acceptance Tests
- User should be able to access a fragment containing information about the given instance
- The user should not be able to interact with the underlying page while the fragment is open
- If a user exits the fragment, the underlying page should be interactable again
- If a user refreshes the page, the fragment should disappear and the underlying page should become active again
- Information that the user sees should be correct for the specific environment
- User should not be able to edit any information displayed
U.S 4.05 - Dev in a Box Status Icon
As a developer I want to be able to separately view the status of each Dev in a Box instance, so that I can easily see the status of the instance on the dashboard rather than in its information menu
Story Point: 2
Acceptance Tests
- User should see a status icon under each instance on the dashboard
- Each status icon should corresponds to the status of the instance it is below
- User should be able to refresh page to update the status
- User should not be able to interact with the status icon itself
U.S 4.06 - Dev in a Box Connected Developers Slider
As a developer I want to be able to separately view a slider for number of people connected to each Dev in a Box instance, so that I can see the number of people on my dashboard rather than in the information menu
Story Point: 3
Acceptance Tests
- User should see a visual slider of number of people on workspace under each instance in dashboard
- Each slider should correspond to the number of people connected to the instance that the slider is below
- User should be able to refresh page to update the information that is displayed by the slider
- User should not be able to interact with the slider itself
U.S 4.07 - Real Time Updates
As a developer I want the status and number of people slider to update in real time (without refresh required), so that I do not need to constantly refresh the page to see this info
Story Point: 2
Acceptance Tests
- User should see that the slider updates correctly without refreshing page
- User should see that the status icon updates correctly without refreshing page
- User should only sees the slider and icon of its corresponding environment
- User should only see a slider and an icon on active environments
U.S 4.08 - Git Lab Link
As an administrator I want the helpful information (URL) to access the Git Lab (subsection of details) to be shown to the administrator upon creation of the Dev in a Box, so that I can save or take note of important information immediately after creation
Story Point: 3
Acceptance Tests
- User should be displayed the information in a fragment after creation of new Dev in a Box
- The displayed information should be in correspondence with the inputted information for creation of the instance
- The underlying page should not be interactable while the fragment is open
- If a user exits the fragment, the underlying page should be interactable again
- If a user refreshes the page, the fragment should disappear and the underlying page should return to active
- User should be able to use information to access the gitlab for that instance
U.S 4.09 - Max Number of Developers per Instance
As an administrator, for each each Dev in a Box instance, I want to be able to adjust the number of developers that can belong to a gitlab, so that I can manage how many people have access
Story Point: 3
Acceptance Tests
- User should be able to edit the number of users allowed in the git lab
- Git lab should respond to the change from the application
- If number is decreased, Git lab should automatically kick out an appropriate number of developers so that the cap is respected
- User cannot enter a number < 1 and > 50
U.S 4.10 - View Subscription Schedules
As an administrator I want to be able to view the subscription schedule for each Dev in a Box instance, so that I know how much longer each instance is available to me, and when the next billing period begins
Story Point: 2
Acceptance Tests
- Administrators should be able to see when their subscription is over (end of billing cycle) if they have previously canceled their subscription
- Subscription should not state an end time if user has not canceled subscription
- User should not be able to see subscription schedule for other environments
- This information should be available within the details fragment
U.S 4.11 - Delete Dev in a Box
As an administrator I want to be able to delete any Dev in a Box at any time, so that I can end the subscription for it
Story Point: 5
Acceptance Tests
- User should be able to delete an environment
- Subscription should stop and user should be reimbursed for remainder of month paid
- Canceling environment should cancel the one specified subscription
- Stripe should confirms termination of subscription
U.S 4.12 - Schedule Dev in a Box Deletion
As an administrator I want to be able to schedule a cancellation of a Dev in a Box at any time, so that the subscription is canceled on a date of my choosing
Story Point: 5
Acceptance Tests
- User should be able to select a date for their environment to be canceled on
- User should not be able to select a date for cancellation that is in the past
- User should be able to update the selected date for cancellation
- Subscription should be ended when stated date is reached
- Subscription should not end before the date is reached
- The user should receive a form in a fragment to input the cancellation date
- The underlying page should not be interactable while the fragment is open
- If a user exits the fragment, the underlying page should be interactable again
- If a user refreshes the page, the fragment should disappear and the underlying page should return to active
U.S 4.13 - Edit Dev in a Box
As an admin I want to be able to edit an existing environment any time so that I can configure them according to my current needs
Story Point: 3
Acceptance Tests
- When user wants to edit an existing instance, user should be brought to a form fill
- If a user exits the form fill they should be returned to the dashboard and no action occurs
- If a user does not fill in the form completely/correctly, the user should not be able to submit the form
- If a user fills in the form completely they should be able to edit an existing instance
- If a user submits the form successfully, they should be returned to the dashboard, and the edited fields should be viewable
- A user should only be able to edit the user count, whether or not to use 'office_in_a_box', and the name of 'office_in_a_box'
- If a user successfully edits the user count, the current billing cycle should end, and a new billing cycle should begin corresponding to the new user count
U.S 4.14 - Role Based User Interface Access
As an administrator I want to be able to see more detailed information about existing environments than a normal user so that I can hide critical/secure information from normal developers.
Story Point: 5
Acceptance Tests
- Only org administrators should be able to edit existing resources and create new resources.
- Only org administrators should be able to manage roles of other users.
- Only org administrators should be able to view critical information, such as passwords and payment details.
MoSCoW
Must Have
- U.S 1.01 - Github Authentication
- U.S 1.05 - Account Saving
- U.S 2.02 - Create New Organization
- U.S 2.03 - Switching Between Organizations
- U.S 2.04 - Inviting Members to Organization
- U.S 3.01 - Payment Information Requirement for Organization
- U.S 3.04 - Pay Via Credit Card
- U.S 4.01 - Create Dev in a Box
- U.S 4.02 - View Dev in a Boxes
- U.S 4.10 - View Subscription Schedules
- U.S 4.11 - Delete Dev in a Box
- U.S 4.13 - Edit Dev in a Box
Should Have
- U.S 1.02 - Google Authentication
- U.S 2.05 - Adjusting Roles within Organization
- U.S 2.06 - Preserving Last Administrator
- U.S 3.06 - Editing Payment Information
- U.S 3.07 - View Payment Information Details
- U.S 4.03 - Dashboard
- U.S 4.04 - Dev in a Box Details
- U.S 4.08 - Git Lab Link
- U.S 4.09 - Max Number of Developers per Instance
- U.S 4.14 - Role Based User Interface
Could Have
- U.S 2.01 - Automatic Default Organization
- U.S 2.07 - Disband Organization
- U.S 2.08 - Remove From Organization
- U.S 3.03 - Variable Charging
- U.S 4.05 - Dev in a Box Status Icon
- U.S 4.06 - Dev in a Box Connected Developers Slider
- U.S 4.07 - Real Time Updates
Would Like But Won't Get
- U.S 1.03 - Username and Password Account Registration
- U.S 1.04 - Username and Password Account Login
- U.S 3.05 - Pay Via 3rd Party Methods
- U.S 3.02 - Payment Information Auto-Fill
- U.S 4.12 - Schedule Dev in a Box Deletion