Skip to content

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

  1. User should be able to open up a github authentication menu by clicking the github button
  2. User should be able to access the rest of the website if they enter a valid github authentication
  3. 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

  1. User should be able to open up a google authentication menu by clicking the google button
  2. User should be able to access the rest of the website if they enter a valid google authentication
  3. 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

  1. User should receive a confirmation email when they register a new email and password
  2. 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

  1. User should be able to sign in with a verified email and password
  2. User should be directed to the rest of the website if they successfully login
  3. User should not be able to sign in with an unverified email and password
  4. 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

  1. If signing in with email and password, user should not have to register a new account
  2. Any payment information already provided should persist between sessions
  3. Any active subscriptions / Dev in a Box products should persist between sessions
  4. Any configuration changes should persist between sessions
  5. 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

  1. After registration, user should belong to an organization and should be the administrator of that organization
  2. The organization should have no other members
  3. The organization should not have any billing information come with it
  4. 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

  1. User should be able to open a form fill that takes parameters for an organization
  2. User should be able to create an organization after form is fully completed
  3. User should not be able to create an organization until form is fully completed
  4. The user’s created organization should be in correspondence with the form fill
  5. The user’s created organization should have no other members
  6. 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

  1. User should be able to see which organizations they belong to
  2. User should be able to select one organization at a time to view their environments
  3. User should have exactly one organization selected at all times
  4. User should only be able to select an organization that they belong to
  5. 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

  1. User should be able to generate an invitation link to send to prospective developers
  2. Someone using that link should be brought to the website and automatically added to the organization after signing in
  3. 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

  1. User should be able to view all members of an organization in one concise panel
  2. User should be able to see which role each member has
  3. User should be able to change the roles of other members
  4. When changing the role, user should get a complete list of available roles
  5. User should be able to confirm their role modifications with a save button
  6. 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

  1. 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

  1. User should see a delete option
  2. User should receive a confirmation message when trying to to delete an organization
  3. Organization should be deleted if confirmation message is accepted
  4. Organization should not be deleted if confirmation message is canceled out of
  5. Organization should not be deleted if >= 1 'Dev in a Box' instances exist
  6. 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

  1. User should be prompted to supply payment information
  2. 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

  1. User should be able to see a list of other payment information available to them and from which organization it is from
  2. User should not be able to payment information from organizations that they are not administrators of
  3. 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

  1. User should pay variable amount based off formula for variable user amount
  2. User should not pay a flat rate subscription
  3. User cannot update without confirmation on the new subscription cost changes
  4. User should not be able to input a non-positive integer number of users when creating environment
  5. 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

  1. User should be able to pay with inputted credit card information
  2. User should get confirmation (from Stripe) that payment is successful
  3. User should get a warning that payment details are incorrect (delivered by Stripe)
  4. User should not be able to pay with debit or other payment methods
  5. 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

  1. User should be able to login to a third party software and pay for a subscription
  2. 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

  1. User should see the same form fill as when creating a new organization for entering payment information
  2. New payment information should only be applied if user selects save and new payment information is verified
  3. 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

  1. 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.
  2. 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

  1. When user wants to add a new instance, user should be brought to a form fill
  2. If a user exits the form fill they should be returned to the dashboard and no action occurs
  3. If a user does not fill in the form completely/correctly, the user should not be able to submit their new subscription
  4. If a user fills in the form completely they should be able to create a new instance
  5. 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
  6. 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

  1. After login, user be able to see a list of all the environments they have access to
  2. User should be able to uniquely identify each environment
  3. User should not be able to see environments that they do not have access to
  4. 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

  1. User should have a dashboard screen to see their environments
  2. All the users environments should be displayed on the dashboard
  3. Each environment should uniquely identifiable, no duplicates
  4. 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

  1. User should be able to access a fragment containing information about the given instance
  2. The user should not be able to interact with the underlying page while the fragment is open
  3. If a user exits the fragment, the underlying page should be interactable again
  4. If a user refreshes the page, the fragment should disappear and the underlying page should become active again
  5. Information that the user sees should be correct for the specific environment
  6. 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

  1. User should see a status icon under each instance on the dashboard
  2. Each status icon should corresponds to the status of the instance it is below
  3. User should be able to refresh page to update the status
  4. 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

  1. User should see a visual slider of number of people on workspace under each instance in dashboard
  2. Each slider should correspond to the number of people connected to the instance that the slider is below
  3. User should be able to refresh page to update the information that is displayed by the slider
  4. 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

  1. User should see that the slider updates correctly without refreshing page
  2. User should see that the status icon updates correctly without refreshing page
  3. User should only sees the slider and icon of its corresponding environment
  4. User should only see a slider and an icon on active environments

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

  1. User should be displayed the information in a fragment after creation of new Dev in a Box
  2. The displayed information should be in correspondence with the inputted information for creation of the instance
  3. The underlying page should not be interactable while the fragment is open
  4. If a user exits the fragment, the underlying page should be interactable again
  5. If a user refreshes the page, the fragment should disappear and the underlying page should return to active
  6. 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

  1. User should be able to edit the number of users allowed in the git lab
  2. Git lab should respond to the change from the application
  3. If number is decreased, Git lab should automatically kick out an appropriate number of developers so that the cap is respected
  4. 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

  1. Administrators should be able to see when their subscription is over (end of billing cycle) if they have previously canceled their subscription
  2. Subscription should not state an end time if user has not canceled subscription
  3. User should not be able to see subscription schedule for other environments
  4. 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

  1. User should be able to delete an environment
  2. Subscription should stop and user should be reimbursed for remainder of month paid
  3. Canceling environment should cancel the one specified subscription
  4. 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

  1. User should be able to select a date for their environment to be canceled on
  2. User should not be able to select a date for cancellation that is in the past
  3. User should be able to update the selected date for cancellation
  4. Subscription should be ended when stated date is reached
  5. Subscription should not end before the date is reached
  6. The user should receive a form in a fragment to input the cancellation date
  7. The underlying page should not be interactable while the fragment is open
  8. If a user exits the fragment, the underlying page should be interactable again
  9. 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

  1. When user wants to edit an existing instance, user should be brought to a form fill
  2. If a user exits the form fill they should be returned to the dashboard and no action occurs
  3. If a user does not fill in the form completely/correctly, the user should not be able to submit the form
  4. If a user fills in the form completely they should be able to edit an existing instance
  5. If a user submits the form successfully, they should be returned to the dashboard, and the edited fields should be viewable
  6. 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'
  7. 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

  1. Only org administrators should be able to edit existing resources and create new resources.
  2. Only org administrators should be able to manage roles of other users.
  3. 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