about requirement specification - N4SJAMK/teamboard-meta GitHub Wiki

Requirement Specification for Contriboard

This document is a specification about non-functional and functional requirements for Contriboard.

Actors / User Roles

User Roles are described inside concept descriptions

Actor/Stakeholder roles

Guest Roles

  • [Guest role - Old user]
  • [Guest role - Young User]
  • [Guest role - Bad Behaving Person]
  • [Guest role - Advanced User]

User Roles

  • [User role - Old user]
  • [User Role - Young User]
  • [User Role - Bad Behaving Person]
  • [User Role - Advanced User]
  • [User Role - User of competitor product]
  • [User Role - Team worker]
  • [User Role - Individualist]

Admin Roles

  • [Developer User]
  • [Service Admin]
  • [Service Developer]
  • [Service Tester]
  • [Service Provider]

Basic Use Scenarios

Primary use case is to provide a virtual collaboration environment for members of selected team. One member logs in as a User and creates a board which can be sent to other members as an URL. Members who receive the url can join the board as Guests who are able to share ideas as virtual "post-it" -tickets on the board.

Customer journey map for primary use case

  • User has registered to Contriboard service.
  • User logs in to Contriboard service.
  • User creates a board and shares it through URL.
  • User invites Guests on the board by sending the URL to specific people.
  • User and all Guests use the same board for sharing ideas.
  • User wraps up the results of the brainstorm session and exports the information as simple format for all participants of the session (e.g. excel, notepad, json).'

General User Interface requirements

Contriboard service is currently divided into five different views. These are as listed below:

Client side requirements

Browser

  • Chrome (+mobile)
  • Firefox (+mobile)
  • Safari (+mobile)
  • Opera (+mobile)
  • Internet Explorer 10 (+mobile)

Installation / Deployment Requirements

Contriboard can be deployed for different purposes:

  • Contriboard can be deployed as a production environment (docker enabled).
  • Contriboard can be deployed as a single node development environment.
  • Contriboard can be deployed as a test environment (docker enabled).

Cloud Production Deployment

Production environment is accessible for public usage.

Cloud Test Deployment

Test environment is used for testing new features in production kind of environment.

Single Node Development environment

Single node development environment is used for developing new features.

  • Developer can install Contriboard as a Vagrant virtual machine.
  • Developer can install Contriboard as a single node with docker enabled.

Non-functional Requirements

Non-functional requirements consists of operations described below.

Security

Usability

Response times for UI

Response Class 0.1 second for main UI functions:

"0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it's selected. Ideally, this would also be the response time for sorting the column — if so, users would feel that they are sorting the table. (As opposed to feeling that they are ordering the computer to do the sorting for them.)" -Jacob Nielsen Criterias

Response Class 1 second for main UI functions:

"1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is "working" on the command, as opposed to having the command be a direct effect of the users' actions. Example: If sorting a table according to the selected column can't be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of "flow" in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor." -Jacob Nielsen Criterias

Response Class 10 second for main UI functions:

"10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user's work, for example when switching tasks." -Jacob Nielsen Criterias

Functional Requirements

Functional requirements consists of behaviors in features described below.

General

Authentication

Workspace

Board

User Interface

Export / Import

Feedback

Integrations

Interfaces

Future Features

  • [Key Shortcuts]