Requirement Specification Document

1. Introduction
1.1 Purpose
The purpose of this document is to outline the detailed requirements for designing a new admin web
application. The application is aimed at managing containers, workspaces, workflows, projects and users
on a server.
1.2 Scope
The application will include a dashboard as the home page, three additional main pages (containers,
workspaces, workflows), user and project management functionalities. The system should provide role-
based security with two roles: admin and developer.

2. System Overview
2.1 System Description
The admin web application will allow users to monitor and manage containers, workspaces, workflows,
and users on a server. The application will capture form data in a database and trigger API requests for
actions on server objects.

3. Functional Requirements
3.1 Dashboard (Home Page)
3.1.1 Display Server Metrics
The dashboard should display memory, CPU, and storage usage of containers running in the server.

3.2 Resources

Confidential 1 Version 1.0

3.2.1.1 List Containers
Display the number of containers in the system.
List attributes should include below elements:

 ContainerId
 Name
 Status
 Created

3.2.1.2 Container Actions

Provide actions for containers:
 Stop
 Start
 Restart
3.2.1.3 Add New Container
A form should be provided to add a new container. Form data should be captured in the database, and an
API request should be triggered for performing any actions.
Below Form elements should be asked to create a new container:

 Name (Input TextBox)

 Description - (Input TextBox)
 Image – drop down list
 Volume - (Input TextBox)
 Network - (Input TextBox)
 Hostname - (Input TextBox)
 Ip - (Input TextBox)
 Ports - (Input TextBox)
 Endpoint - (Input TextBox)
When submit button is pressed on the form then the page content should be submitted to the custom api.
In addition to this the data captured for each individual form element should be stored to the backend
local database.

3.2.2 List Images

Display Images in the system.
List attributes should include below attributes

 ImageId
 Repository

Confidential 2 Version 1.0

  Tag
 Created
 Size

3.3 Workspaces
3.3.1 List Workspaces
Display the number of workspaces in the system.
List attributes should include below elements:

 WorkspaceID
 Name
 Status
 Created
 IsActive – (checkbox if active)

3.3.2 Workspace Actions

Provide actions for workspaces:
 Stop
 Start
 Recreate
3.3.3 Add New Workspace
A form should be provided to add a new workspace. Form data should be captured in the database, and an
API request should be triggered for performing any actions.
Below Form elements should be asked to create a new workspace:

 Name (Input TextBox)

 Description - (Input TextBox)
 Source - - (Input TextBox)
 Repository- (Input TextBox)
 Providers – drop down list
 IDE - (Input TextBox)
When submit button is pressed on the form then the page content should be submitted to the custom api.
In addition to this the data captured for each individual form element should be stored to the backend
local database.

3.4 Workflows

Confidential 3 Version 1.0

3.4.1 List Workflows
Display the number of workflows in the system.
List attributes should include below elements:

 WorkflowId
 Name
 Status
 Created
 IsActive – (checkbox if active)

3.4.2 Workflow Actions

Provide actions for workflows:
 Stop
 Start
 Restart
3.4.3 Add New Workflow
A form should be provided to add a new workflow. Form data should be captured in the database, and an
API request should be triggered for performing any actions.
Below Form elements should be asked to create a new container:

 Name (Input TextBox)

 Description - (Input TextBox)
 Param1 – (Text Area) should have a + button, where when pressed another instance of param1
should be added with TextArea
 Param2 – (Text Area) should have a + button, where when pressed another instance of param2
should be added with TextArea
When submit button is pressed on the form then a json object should be generated with the entire content
of the form page and the page content should be submitted to the custom api. In addition to this the data
captured for each individual form element should be stored to the backend local database.

3.5 User Management

3.5.1 Add/Update/Delete User
A panel should be provided to add, update, and delete users. Form data should be captured in the database
along with CRUD operations. In addition to that api request should be triggered for any action
(add/update/delete users from the system)
3.6 User Authentication
3.6.1 Signup/Register

Confidential 4 Version 1.0

Provide an interface for users to signup/register to the application.
3.6.2 Login
Include a login page for users to authenticate.
3.6.3 Logout
Include a logout functionality for users to securely log out.
3.7 Project Management
3.7.1 Add/Update/Delete Projects
A panel should be provided to add, update, and delete projects. Form data should be captured in the
database along with CRUD operations.

4. Security Requirements
4.1 Role-Based Security
Provide two roles:
 Admin: Has all rights
 Developer: Cannot add new users/projects
4.2 User and Project Management
Admin users should be able to:
 Add new users
 Add new projects
 Assign users to a project

5. Non-Functional Requirements
5.1 Performance
The application should have low latency and respond quickly to user interactions.
5.2 Reliability
The system should be reliable, ensuring minimal downtime and data loss.
5.3 Scalability
The application should be scalable to accommodate an increasing number of users and server objects.

6. Conclusion

Confidential 5 Version 1.0

This requirement specification document provides a detailed outline of the features and functionalities
required for the design of the new admin web application. The document serves as a foundation for
development and testing activities.

Confidential 6 Version 1.0