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
