Computer Engineering Department

Government College of Engineering & Research Avasari Khurd

Savitribai Phule Pune University

Final Year of Computer Engineering

2025-26 Semester I

Software Requirement Specification

● Project Group ID: 11

● Title of the Project: Custard :Cross-platform terminal for developers

● Project Guide: Prof. P.V. RAJHANS

● Team Members:
Sr. Roll No Name Email Mobile Sign
1. 22121048 Sahil Borse [email protected] 7385858428
2. 22121039 Pritul Raut [email protected] 9673977771
3. 22121033 Shraddha shendgeshraddha@[email protected]. 9322831231
Shendge in
4. 23221031 Sakshi Kedari kedarisakshi@[email protected] 9673929944

Date: Guide Signature Project Coordinator Signature

Prof. P. V. RAJHANS Prof. P. V. RAJHANS 1
Revision History 1
1. Introduction 1
1.1 Purpose 1
1.2 Document Conventions 1
1.3 Intended Audience and Reading Suggestions 1
1.4 Project Scope 2
1.5 References 3
2. Overall Description 4
2.1 Product Perspective 4
2.2 Product Features 4
2.3 User Classes and Characteristics 4
2.4 Operating Environment 5
2.5 Design and Implementation Constraints 5
2.6 User Documentation 5
2.7 Assumptions and Dependencies 6
3. System Features 7
4. External Interface Requirements 9
4.1 User Interfaces 9
4.2 Hardware Interfaces 9
4.3 Software Interfaces 9
4.4 Communications Interfaces 10
5. Other Nonfunctional Requirements 11
5.1 Performance Requirements 11
5.2 Safety Requirements 11
5.3 Security Requirements 11
5.4 Software Quality Attributes 12
6. Other Requirements 13
Appendix A: Glossary 14
Appendix B: Analysis Models 15
Sequence Diagram: 17
7. Class Diagram: 18
Appendix C: Issues List 19

Revision History
Name Date Reason For Changes Version
1. Introduction
1.1 Purpose
The product is a standalone, intelligent command-line terminal designed to run on
Windows, Linux, and macOS. This SRS covers the complete scope of the application,
which includes the core functionality of translating commands between user-selected
dialects (Windows CMD and Linux Bash), executing the translated commands on the host
operating system, maintaining a command history, and providing a fallback mechanism
using the Small Language Model API for unrecognized commands. This document defines
the features, capabilities, and constraints for the initial release of the Custard terminal.

1.2 Document Conventions

This document uses the following standards and typographical conventions:

• Bold text is used to highlight key terms, section headings, and concepts of special
significance.
• Monospaced font is used to denote code, user-input commands, file names, and
system output.
• Italics are used for emphasis and to introduce new terms.
• The terms "the system," "the terminal," and "Custard" are used interchangeably to
refer to the software product.
• All functional and non-functional requirements =are uniquely identified with a
numbered prefix (e.g., FR-01, NFR-01) for clear traceability.
• Each individual requirement statement throughout this document is assigned its
own priority level (High, Medium, or Low). Priorities for higher-level requirements
are not assumed to be inherited by detailed sub-requirements.

1.3 Intended Audience and Reading Suggestions

This document is intended for a variety of readers who have different interests in the
Custard project. The document is organized to allow each reader to focus on the sections
that are most relevant to them.

Organization of this SRS:

• Section 1 (Introduction) provides an overview of the project's purpose, scope, and this
document itself.
• Section 2 (Overall Description) describes the product from a high-level perspective,
including its key features, user characteristics, and operational environment.
• Section 3 (Specific Requirements) contains the detailed functional and non-functional
requirements, which form the core of the specification that must be implemented.
 • Section 4 (System Architecture) (and subsequent sections) will detail the system design,
data flow, and other technical diagrams.

Reader Types and Reading Suggestions:

• Developers: Are the primary audience for the entire document. It is essential to read all
sections to gain a complete understanding of what needs to be built.
o Suggested Reading Path: Start with Sections 1 and 2 for a high-level context, then
proceed to Section 3 for the detailed requirements that will guide implementation.
• Project Managers & Stakeholders: Need to understand the project's goals, scope, and
high-level features to manage its progress and ensure it meets business objectives.
o Suggested Reading Path: Focus on Section 1 (Introduction) and Section 2 (Overall
Description).
• Testers (QA Team): Will use this document to create test plans and cases to verify that the
software meets its specified requirements.
o Suggested Reading Path: Read Sections 1 and 2 for context, then conduct a
detailed review of Section 3 (Specific Requirements) as this is the basis for all
testing activities.
• Users: While this document is technical, end-users may be interested in the planned
features and capabilities of the terminal.
o Suggested Reading Path: Review Section 1.4 (Project Scope) and Section 2.2
(Product Features) for a clear overview of what the application will do.
• Documentation Writers: Need to understand the system's functionality to produce user
manuals and help guides.
o Suggested Reading Path: Read the entire document, paying close attention to
Section 2 (Overall Description) and Section 3 (Specific Requirements) to ensure all
features are accurately documented.

1.4 Project Scope

The "Custard" project is a smart, cross-platform terminal designed to simplify the
command-line experience for developers, students, and system administrators. Its primary
purpose is to bridge the gap between different operating system shell environments,
specifically Windows and Linux.

The key benefit of Custard is a significant increase in user productivity by eliminating the
need to search for command syntax and equivalents when switching between operating
systems. This creates a smoother, more intuitive workflow. The main objective is to build
a functional terminal that provides real-time, plain-language command translation,
reducing the cognitive load on the user. The project's central goal is to make the
command-line interface more accessible and less intimidating, especially for beginners,
thereby fostering a better learning environment.

This project aligns with the broader educational goal of providing students with practical
experience in system-level programming, cross-platform development, and API integration.
For the wider developer community, it offers a tool that can streamline development
workflows in mixed-OS environments.

This SRS specifies Version 1.0 of the Custard terminal. The scope for this release
includes:

• A fully functional command-line interface that can run on Windows, Linux, and
macOS.
• Real-time translation for a core set of common commands between Windows CMD
and Linux Bash dialects.
• Support for command history and recall.
• The ability to parse and translate commands that use pipes.
• A set of essential built-in commands (help, history, exit, etc.).
• A placeholder for future integration with the Small Language Model API for handling
unrecognized commands.

Advanced features such as scripting, full GUI support, and comprehensive translation of all
possible commands are considered out of scope for this version but may be considered for
future releases.

1.5 References
• https://arxiv.org/abs/1907.05308
• https://en.wikipedia.org/wiki/Cross-platform_support_middleware
• https://www.thegreenreport.blog/articles/achieving-test-nirvana-with-cross-platform-shell-scripts
• https://arxiv.org/abs/2104.14614
• https://www.researchgate.net/publication/357031720
2. Overall Description
2.1 Product Perspective

The Universal Terminal is a new, self-contained product designed to simplify the

command-line interface (CLI) experience. It acts as an abstraction layer between the user
and the underlying operating system (OS) kernel. Unlike traditional shells, which are tightly
coupled to a single OS, this software provides a unified experience across different
platforms.

The terminal's primary function is to translate a user's familiar commands (e.g., from
Linux) into the syntax required by the host OS (e.g., Windows). It also includes a Small
Language Model API fallback for providing real-time, helpful information on unfamiliar or
unrecognized commands. It does not replace the OS kernel but rather serves as a front-
end shell that communicates with it through system calls.

2.2 Product Features

The Universal Terminal offers several key features:

• Cross-Platform Command Translation: It automatically maps commands from a

user's preferred dialect (Windows or Linux) to the host OS's native syntax.
• Real-time Command Descriptions: It leverages a Small Language Model API to
provide plain-language explanations, syntax examples, and suggestions for
commands.
• Command History and Expansion: Users can recall and reuse previous
commands with built-in functionality like !! and !n.
• Non-Intrusive Interface: The user interface is clean and simple, providing only the
necessary information without clutter.

2.3 User Classes and Characteristics

The target user base is primarily composed of two main classes:

• New Users: These users may be new to the command line or transitioning between
different operating systems. Their primary goal is to perform basic file and directory
operations without memorizing different command syntaxes. This is the favored
user class, as the product's core features are designed to address their pain
points.
• Experienced Users: These users are comfortable with the command line but may
work in a multi-OS environment. They will appreciate the efficiency of not having to
switch their mental "dialect" when moving from a Linux to a Windows machine, and
they can use the Small Language Model fallback for quick checks on less-frequently
used commands.
2.4 Operating Environment

The Universal Terminal is designed to run on the following platforms:

• Hardware Platform: Any standard PC hardware (x86, x64, ARM) with sufficient
memory and processing power to run a modern operating system.
• Operating System:
o Windows: Windows 10 and later.
o Unix-like: Linux (e.g., Ubuntu, Fedora) and macOS.
• Software Components: The application relies on standard C libraries and the
system() function to execute commands. It also requires a network connection to
communicate with the Small Language Model API via a tool like curl.

2.5 Design and Implementation Constraints

• Language: The software will be developed in C to ensure high performance and

cross-platform compatibility.
• API Key: A valid Small Language Model API key is required for the fallback
functionality. This key must be securely managed and is a dependency.
• Dependencies: The use of system() for command execution and curl for API calls
are fixed constraints.
• Security: All API communication will be secured using standard protocols.

2.6 User Documentation

The product will be delivered with the following user documentation:

• README.md: A file providing a quick start guide, covering installation, basic usage,
and a list of supported commands.
• On-line Help: Built-in help within the terminal, accessible via a command like help,
that provides information on the terminal's features and built-in commands.
2.7 Assumptions and Dependencies

• Small Language Model API Stability: It is assumed that the Small Language
Model API will be available and its functionality will remain consistent. Any changes
to the API could require updates to the terminal's code.
• Network Connectivity: The Small Language Model API fallback is dependent on a
stable internet connection. Without one, this feature will not function.
• curl Availability: It is assumed that the curl command-line tool or a similar utility is
available on the host system to make API requests.
• Standard OS Commands: The command translation depends on the assumption
that the core, mapped commands (like dir, ls, copy, cp) are present and behave as
expected on their respective host operating systems.
3. System Features
3.1 System Feature: Cross-Platform Command Translation

• Description and Priority

o Translates commands between user-selected Windows and Linux dialects to
match the host OS. Priority: High.
• Stimulus/Response Sequences
o Stimulus: A user on Windows (with Linux dialect) types of ls -l.
o Response: The system executes the dir command and displays the output.
• Functional Requirements
o REQ-1: The system shall allow the user to select an input dialect (Windows
or Linux) upon startup.
o REQ-2: The system shall map common commands and their arguments
between platforms (e.g., ls -a to dir /a, cat to type).
o REQ-3: The system must handle file paths with spaces.
o REQ-4: Unmapped commands shall be passed directly to the host shell for
execution.

3.2 System Feature: Command History Management

• Description and Priority

o Maintains a record of user commands for easy recall and re-execution.
Priority: High.
• Stimulus/Response Sequences
o Stimulus: A user runs a command, then types!!.
o Response: The system re-executes the most recent command.
• Functional Requirements
o REQ-5: The system shall store a numbered list of commands entered during
a session, viewable with the history command.
o REQ-6: The system shall support shortcuts to re-execute the last command
(!!) or a specific command by number (!n).
o REQ-7: The system shall show an error if a user tries to recall a history
number that does not exist.
o REQ-8: The history log shall be capped at a maximum size, discarding the
oldest entries first.

3.3 System Feature: Command Execution and Pipeline Handling

• Description and Priority

 o Executes translated commands and handles piped command chains.
Priority: High.
• Stimulus/Response Sequences
o Stimulus: User types ls | grep ".txt".
o Response: The system translates and executes the piped command (e.g.,
dir | findstr ".txt" on Windows).
• Functional Requirements
o REQ-9: The system shall execute commands using the host OS's native
shell and display the output.
o REQ-10: The system must parse, translate, and correctly execute commands
chained with pipe (|) operators.
4. External Interface Requirements
4.1 User Interfaces

The Universal Terminal is a command-line interface (CLI) application. It does not have a
graphical user interface (GUI).

• Input: The primary user interface is a text-based input line. Users type commands
and press Enter to execute them.
• Prompt: A simple, non-intrusive command prompt will be displayed, indicating the
chosen input dialect (e.g., cmd> for Windows syntax or bash> for Linux syntax).
• Output: All output, including command results, error messages, and descriptions
from the Small Language Model API, is displayed as plain text directly below the
command line.
• Error Messages: Error messages will be clear, concise, and easy to understand.
For instance, a failure to execute a command will be followed by a prompt indicating
that the Small Language Model API is being used as a fallback.
• Command History: Users can navigate command history using the up and down
arrow keys.

4.2 Hardware Interfaces

The software does not have direct interfaces with specific hardware components. It
interacts with the hardware indirectly through the underlying operating system and its
standard libraries.

• Keyboard: The primary input device for user commands.

• Display: The output from the terminal is rendered on the system's display.
• Network Adapter: Required for the Small Language Model API communication.

4.3 Software Interfaces

The Universal Terminal interfaces with several key software components:

• Operating System (OS): The core interface is with the host OS (Windows or
Linux). The terminal uses the OS's system call interface to execute commands,
specifically through the system() function in C.
• Standard C Libraries: The application relies on standard C libraries for functions
like string manipulation (string.h), standard input/output (stdio.h), and process
control (stdlib.h).
 • curl: This external command-line tool is a critical dependency for making HTTP
requests to the Small Language Model API. The terminal will spawn a child process
to run curl.
• Small Language Model API: The terminal communicates with the Small Language
Model API to get command descriptions and suggestions. It sends the user's input
as a command and receives a JSON response. The format of the API request and
the expected response structure are documented separately.

4.4 Communications Interfaces

The only communication interface required is for the Small Language Model API
fallback.

• Protocol: HTTPS will be used for all communication to ensure data security.
• Mechanism: The curl command-line utility will be used to send HTTP POST
requests to the Small Language Model API endpoint.
• Data Format: The request body will be a simple JSON object containing the user's
command. The response from the API will also be in JSON format.
5. Other Nonfunctional Requirements
5.1 Performance Requirements

• PR-1: Command Latency: The time between a user pressing "Enter" and the
display of the first character of the output shall not exceed 100 milliseconds for
commands handled internally (e.g., history) or directly by the OS.
• PR-2: API Response Time: The time to receive and display a response from the
Small Language Model API should not exceed 2 seconds. This is crucial for
maintaining a responsive user experience when the command translation fails.
• PR-3: Resource Usage: The terminal application's memory footprint shall remain
minimal, ideally below 50MB during normal operation, to ensure it doesn't impact
other running processes on the host machine.

5.2 Safety Requirements

The Universal Terminal does not pose a direct threat to safety in its operation. It does not
control critical hardware or systems. However, as it executes commands on the underlying
OS, it is important to implement safeguards to prevent unintentional data loss or system
damage.

• Command Execution: The terminal will not execute potentially destructive

commands (e.g., rm -rf /) without a clear warning or user confirmation, especially if
the command is a result of a translation.
• Data Integrity: The application will not modify or delete user data on its own. It will
only execute commands as requested by the user.

5.3 Security Requirements

• API Key Security: The Small Language Model API key must not be hardcoded
into the final application. It should be stored securely in an environment variable or
a configuration file that is not publicly accessible.
• Input Sanitization: User input will be properly sanitized to prevent injection attacks
or other malicious code from being passed to the OS's system() function.
• Communication Security: All communication with the Small Language Model API
will be over HTTPS to ensure data integrity and confidentiality.
5.4 Software Quality Attributes

• Portability: The software must be easily compiled and run on different operating
systems, including Windows, Linux, and macOS. This is a core attribute of the
project.
• Usability: The interface should be clean and non-intrusive, making it easy for
novice users to get started. The Small Language Model API fallback is a key feature
to enhance usability by providing on-the-fly assistance.
• Reliability: The terminal should handle various user inputs gracefully. If a command
fails to execute, it should clearly inform the user and not crash. The Small Language
Model API fallback is a crucial part of this reliability.
• Maintainability: The codebase should be well-structured and commented, allowing
future developers to easily understand and modify the command mapping logic and
other features.
6. Other Requirements
6.1 Internationalization Requirements

• LANG-1: All user-facing text, such as prompts and help messages, shall be written
in English.
• LANG-2: The terminal must support the standard ASCII character set for all
command inputs and outputs. Support for extended character sets (e.g., UTF-8) for
file and directory names is a low-priority future consideration.

6.2 Legal and Licensing Requirements

• LEGAL-1: The project shall be licensed under a permissive open-source license

(e.g., MIT License) to encourage adoption and contribution from the community.
• LEGAL-2: The application must not include any third-party libraries or code that
have incompatible licenses.

6.3 Reuse Objectives

• REUSE-1: The core command parsing and mapping engine should be designed as
a modular component. This will allow it to be potentially extracted and reused in
other developer tools or integrated development environments (IDEs) in the future.
Appendix A: Glossary
• API: Application Programming Interface. A set of rules and tools for building
software and applications. In this project, it refers to the Small Language Model API
used for AI-powered command assistance.
• CLI: Command-Line Interface. A text-based interface used for running programs,
managing computer files, and interacting with the system.
• Command Mapping: The core process within the Custard terminal of translating a
command from a source dialect (e.g., Linux ls) to the host OS's native equivalent
(e.g., Windows dir).
• Dialect: Refers to a specific command-line syntax style. In this project, the two
dialects are Windows (CMD) and Linux (Bash).
• Host OS: The primary operating system on which the Custard terminal application
is currently being executed.
• OS: Operating System. The software that manages all of the hardware and software
resources of a computer (e.g., Windows, Linux, macOS).
• Pipe (|): A command-line operator that sends the output of one command to the
input of another command for further processing.
• REQ: An abbreviation for "Requirement." Used as a prefix to uniquely identify each
functional requirement in this document.
• SRS: Software Requirements Specification. A document that describes what a
software system should do and how it should perform.
• System Call: A request made by a program to the operating system's kernel for a
service, such as file I/O or process execution.
• TBD: To Be Determined. A placeholder used in this document to indicate that a
specific detail is not yet finalized.
Appendix B: Analysis Models

Data flow diagrams

DFD LEVEL 0

DFD LEVEL 1
DFD LEVEL 2
AI FLOW DIAGRAM

Sequence Diagram:
7. Class Diagram:
Appendix C: Issues List
01: Full Small Language Model API Integration (Status: TBD)

• The current implementation contains a mock API call. The final implementation
requires selecting a C library for HTTP requests (e.g., libcurl), securing an API key,
and defining the final JSON payload and parsing logic for the AI fallback.

02: Definitive Scope of Command Mapping (Status: Pending Decision)

• While many common commands are mapped, the full extent of command options
and less common commands to be supported is not finalized. A priority list needs to
be established for which commands and flags to implement next.

03: Spell Check Implementation Details (Status: TBD)

• The requirement for an interactive spell checker (REQ-12) has been defined, but
the technical approach, including the dictionary source and the suggestion
algorithm, has not yet been designed.

04: Confirmation Prompt for Destructive Commands (Status: Pending Decision)

• The safety requirement (SAF-01) calls for a confirmation mechanism for destructive
commands. The exact user interface for this (e.g., [Y/N] prompt, specific flags to
trigger it) needs to be finalized.

05: Official macOS Compatibility Testing (Status: Information Needed)

• The application is designed to be portable to Unix-like systems, but dedicated

testing and validation on macOS have not been performed. There may be minor
compatibility issues or platform-specific commands that need to be addressed