Electronics Engineer's Advanced Calculator

The system shall correctly perform addition (+), subtraction (-), multiplication (×), and division (÷). The system shall provide trigonometric functions: sin, cos, tan. The system shall provide inverse trigonometric functions: asin, acos, atan. The system shall provide the logarithm function (log), natural log function (ln), exponential function (exp), power function (x^y), square root function (√), and factorial function (!). The calculator shall support calculations in Degrees, Radians, and Gradians, with a UI control to switch between modes and a clear display of the active mode. The output of all trigonometric functions shall correctly reflect the selected angle mode. The UI shall provide dedicated access to constants Pi (π), Euler's number (e), Boltzmann constant (k), and elementary charge (e). The calculator shall support undo (Ctrl+Z) and redo (Ctrl+Y) for the input expression. The primary display shall show the current input and result, with a scrollable history panel for previous calculations. Clicking a history item shall load it for re-use. The system shall correctly parse inputs with SI prefixes (p, n, μ, m, k, M, G). The system shall provide configurable engineering notation for results, including a default unit. The calculator shall provide memory functions (M+, M-, MR, MC). Users shall be able to assign, use, view, and manage variables (`variableName = expression`). All memory values and user-defined variables shall be persisted across sessions. The system shall provide clear, non-destructive error messages for invalid operations or syntax errors, preserving the user's original input. The system shall include a comprehensive, searchable in-app help system accessible from a global UI element as defined in REQ-UI-001. This system shall provide clear documentation on all application features, including: (a) Core calculator functions and constants, (b) Specialized electronics modes, (c) The custom mode creation process, and (d) User account management. The implementation shall leverage a suitable open-source library for help content authoring and presentation (e.g., MkDocs, Docusaurus). A formal process for creating, reviewing, and maintaining help content shall be established, with ownership assigned to the product team to ensure accuracy and completeness. User requested modification to add a comprehensive help tool. This enhancement formalizes the feature, specifies its scope, mandates the use of an open-source component, and addresses the identified content definition gap by requiring a formal content creation and maintenance process.

The UI shall be clean, modern, and intuitive. The application layout shall be fully responsive, providing an optimal user experience on devices from small mobile screens to large desktop monitors. The UI shall adhere to Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards, including proper color contrast, full keyboard navigability, and screen reader support. The system shall provide a Main Calculator View, Mode-Specific Views, a Custom Mode Wizard, a Custom Mode Management view, and Login/Registration screens. The UI shall utilize a modern, professional color palette, defined in a formal style guide to ensure consistency and mitigate design subjectivity. This palette must enhance usability, reduce eye strain, and align with the application's branding. The UI shall incorporate subtle, performant micro-interactions (e.g., for button presses, state changes, input validation feedback) to provide clear visual cues without disrupting the user workflow. A globally accessible UI element (e.g., a persistent icon in the main navigation bar) shall serve as the entry point to the in-app help system defined in REQ-FRC-001. Enhanced to formalize subjective user requests for 'cool colors' and 'advance interactivity' into actionable specifications for a professional color palette and performant micro-interactions. Also incorporates the ripple effect from REQ-FRC-001 by adding the requirement for a globally accessible entry point to the new help system.

The system shall implement a CI/CD pipeline using GitHub Actions, triggered on push to any branch. The pipeline shall include stages for Lint & Test, Security Scan, Build, Push to Amazon ECR, and Deploy via Terraform. The Build stage shall be configured to handle both application code and documentation, ensuring that the help content defined in REQ-FRC-001 is built and included in the final deployment artifact. The system shall use Terraform to define and manage all cloud infrastructure resources. The system shall use Terraform workspaces to maintain separate, isolated state for `dev`, `staging`, and `prod` environments. All sensitive data shall be stored in AWS Secrets Manager and retrieved by the application at runtime, not hardcoded in the repository. Enhanced to address the ripple effect from the introduction of a new help system in REQ-FRC-001. The CI/CD pipeline specification is updated to explicitly include a stage for building and packaging the help documentation, ensuring it is consistently deployed with the application.

The client application shall communicate with the backend exclusively through a RESTful API. The API protocol shall be REST over HTTPS. The API data format shall be JSON. All authenticated API endpoints shall require a JWT Bearer token in the `Authorization` header. The API shall be versioned via the URL path (e.g., `/api/v1/...`). The application shall integrate with an external Identity Provider (IdP) for user authentication. All communication between the client and server shall use HTTPS with TLS 1.2 or higher.

The system shall employ a Serverless Microservices Hybrid architecture. The system shall include a React-based Single Page Application (SPA) client, an API Gateway, a containerized User & Data Service on AWS ECS, a secure AWS Lambda for the Formula Execution Service, and a managed PostgreSQL instance (Amazon RDS). The frontend framework shall be React 18+ with TypeScript, using Redux Toolkit for state management and Vite as the build tool. The backend language and framework shall be Node.js (LTS) with NestJS, exposing a RESTful API. The formula execution platform shall be AWS Lambda with a Node.js runtime, using the `vm2` library for sandboxing. The database shall be PostgreSQL 15+ via Amazon RDS. The infrastructure shall use AWS, Docker, AWS ECS with Fargate, GitHub Actions for CI/CD, Terraform for IaC, and AWS Secrets Manager for secret management.

The system shall enforce that SI prefixes (p, n, μ, m, k, M, G) are case-sensitive and appended directly to a number with no space. The system shall enforce that Resistance (R) in the Ohm's Law calculator is a positive number. The system shall enforce that Power (P) in the Ohm's Law calculator is a non-negative number. The system shall enforce that all resistor values in the Resistor Combination calculator are positive and non-zero. The system shall enforce that the requested duty cycle in the 555 Timer Astable mode is greater than 50% and less than 100%. The system shall warn, but not prevent, calculations that result in 555 Timer component values outside a practical range. The system shall enforce that user passwords meet minimum complexity requirements (e.g., 8 characters, 1 uppercase, 1 lowercase, 1 number).

The application shall be built using a technology stack of React/TypeScript for the frontend. The application shall be built using a technology stack of Node.js/NestJS/PostgreSQL for the backend. The application shall be deployed on AWS. The application shall leverage AWS managed services including ECS, Lambda, and RDS. All user-defined formulas shall be executed within a secure, isolated sandbox using the `vm2` library on AWS Lambda. The sandbox environment shall have no network access. The sandbox environment shall have no filesystem access. The sandbox environment shall have strict resource limits. The file format for exporting and importing custom modes shall be JSON.

The system shall have a `users` entity with fields: `id`, `auth_provider_id`, `email`, `created_at`, `updated_at`. The system shall have a `custom_modes` entity with fields: `id`, `user_id`, `name`, `description`, `definition` (JSONB), `created_at`, `updated_at`. The system shall have a `user_variables` entity with fields: `id`, `user_id`, `name`, `value`, `created_at`, `updated_at`, and a unique constraint on (`user_id`, `name`). The system shall have a `calculation_history` entity with fields: `id`, `user_id`, `expression`, `result`, `created_at`. The system shall use the `JSONB` data type in PostgreSQL for the `definition` column in the `custom_modes` table. The system shall create indexes on all foreign keys and columns frequently used in `WHERE` clauses. The database shall have automated daily snapshots and point-in-time recovery enabled as per NFR-SAFE-01.

The client application shall run on a modern, standards-compliant web browser, including the latest versions of Chrome, Firefox, Safari, and Edge. The client application shall run on any desktop or mobile operating system. The entire backend infrastructure shall be hosted on Amazon Web Services (AWS). The client shall require an active internet connection to authenticate and synchronize data with the backend. Core calculator functions shall operate offline after the initial application load. Custom modes and data persistence shall require an active internet connection.

The UI shall present four input fields for Ohm's Law and Power mode: V, I, R, and P. When the user enters valid numerical data into any two of the Ohm's Law fields, the other two fields shall be automatically calculated and populated in real-time. Ohm's Law calculations shall be correct based on the formulas V=IR and P=VI. Ohm's Law input fields shall only accept valid numerical data. <<$Addition>> Justification: Prevents calculation errors and guides the user toward correct usage of the tool. The system shall display a message prompting for more information if an Ohm's Law calculation is attempted with fewer than two inputs. <<$Addition>> Justification: Prevents calculation errors and guides the user toward correct usage of the tool. The system shall flag negative values entered for Resistance (R) or Power (P) with a validation error. <<$Addition>> Justification: Prevents calculation errors and guides the user toward correct usage of the tool. The Resistor Combinations UI shall allow a user to create and manage a dynamic list of resistor values. The user shall be able to add, edit, and remove values from the resistor list. A "Calculate Series" button shall calculate the sum of all resistor values in the list. A "Calculate Parallel" button shall calculate the equivalent resistance using the formula `1 / (1/R1 + 1/R2 + ... + 1/Rn)`. The Resistor Combinations list shall only accept positive, non-zero resistance values. <<$Addition>> Justification: Ensures physically meaningful calculations. In the Resistor Color Code mode, the user shall first select the resistor type to be converted: 3, 4, 5, or 6-band. <<$Change>> Justification: The original requirement was ambiguous; specifying band counts makes it implementable. Suggesting E-series values adds practical value by guiding users to commercially available components. For Value-to-Color conversion, the user shall enter a resistance value and select a tolerance from a dropdown of standard values. For Value-to-Color conversion, the system shall display the correct sequence of color bands for the specified resistor type. If a non-standard resistance value is entered, the tool shall suggest the nearest standard E-series value. <<$Addition>> Justification: The original requirement was ambiguous; specifying band counts makes it implementable. Suggesting E-series values adds practical value by guiding users to commercially available components. For Color-to-Value conversion, the UI shall display a color palette for each of the selected number of bands. As the user selects colors, the system shall display the corresponding resistance value, tolerance, and (for 6-band resistors) the temperature coefficient. For 555 Timer Astable Mode, the UI shall require three inputs: desired Frequency, desired Duty Cycle, and the value of ONE known component (RA, RB, or C). <<$Change>> Justification: The change to inputs resolves a mathematical impossibility (CONT-001). The business rules and practicality checks add a layer of expert guidance, making the tool more useful for real-world circuit design. For 555 Timer Astable Mode, the system shall calculate and display the values for the remaining two components. For 555 Timer Astable Mode, the system shall validate that the desired duty cycle is greater than 50% and display an informative error if it is not. <<$Addition>> Justification: The change to inputs resolves a mathematical impossibility (CONT-001). The business rules and practicality checks add a layer of expert guidance, making the tool more useful for real-world circuit design. For 555 Timer Monostable Mode, the UI shall require two inputs: desired Pulse Width and the value of ONE known component (R or C). <<$Change>> Justification: The change to inputs resolves a mathematical impossibility (CONT-001). The business rules and practicality checks add a layer of expert guidance, making the tool more useful for real-world circuit design. For 555 Timer Monostable Mode, the system shall calculate and display the value for the remaining component. For both 555 Timer modes, if a calculated component value falls outside a typical practical range, the system shall display a non-blocking warning message. <<$Addition>> Justification: The change to inputs resolves a mathematical impossibility (CONT-001). The business rules and practicality checks add a layer of expert guidance, making the tool more useful for real-world circuit design.

The system shall provide a user registration flow requiring a valid email and a secure password. The system shall provide a login flow for existing users. All communication during registration and login shall be encrypted. Upon successful login, the user's calculation history, defined variables, and created custom modes shall be loaded from the backend. <<$Addition>> Justification: Addresses GAP-001, ensuring the core utility of the application by retaining user work between sessions. Any changes to user data (new calculations, variables, modes) shall be saved to the backend. User data shall be securely associated with the logged-in user and not be accessible by any other user.

The custom mode creation process shall be a multi-step wizard. The user shall provide a unique Name and an optional Description for the mode. The user shall define one or more Input Variables and one or more Output Variables. For each variable, the user shall specify a name and may specify a unit. The user shall enter one or more formulas using standard algebraic syntax, with support for standard math functions and the constant `pi`. The formula editor shall provide real-time syntax validation and highlight user-defined variables. The user shall be able to customize display labels and choose the input control type (e.g., text field, slider). Upon successful creation, the new mode shall be available for use immediately. A dedicated section in the UI shall list all available custom modes. Clicking on a custom mode shall open its dedicated interface, displaying the defined input and output fields. As the user enters valid numerical values into the input fields, the output fields shall be calculated and updated in real-time. A dedicated management screen shall list all user-created modes. From the management screen, a user shall be able to Launch, Edit, Delete, and View the details of a mode. <<$Addition>> Justification: This addresses GAP-006 by providing the essential lifecycle management features for user-generated content. Deleting a mode shall trigger a confirmation prompt before deletion. Editing a mode shall re-open the creation wizard populated with that mode's data. The Custom Mode Management screen shall provide an "Export" option for each mode. <<$Change>> Justification: This defines a clear and feasible mechanism for sharing (GAP-007), avoiding the ambiguity of a more complex online repository. Exporting a mode shall generate and prompt the user to download a structured JSON file containing the complete mode definition. The application shall provide an "Import" function that allows a user to upload a valid mode definition JSON file. Upon successful import, the new mode shall be added to the user's list of custom modes and be immediately available for use.

The system shall use Amazon CloudWatch Metrics to collect performance and utilization metrics from all AWS resources. All application and system logs shall be centralized in Amazon CloudWatch Logs in a structured JSON format. The system shall integrate AWS X-Ray for distributed tracing of requests. CloudWatch Alarms shall be configured to automatically notify the development team for critical events. An alarm shall be triggered if the API Gateway 5xx error rate exceeds 1% over a 5-minute period. An alarm shall be triggered if the P99 API latency exceeds 1 second. An alarm shall be triggered if an ECS service CPU or Memory utilization exceeds 80%. An alarm shall be triggered for Lambda function execution errors or timeouts.

All client-side calculations and UI updates shall complete in under 50ms. All API calls for data retrieval shall have a 95th percentile (P95) response time of less than 200ms. The execution of a user-defined custom formula via the backend service shall have a P95 response time of less than 500ms.

The backend services shall have a target uptime of 99.9%, excluding planned maintenance. Planned maintenance windows shall be scheduled during periods of low user activity and communicated to users in advance. The system architecture shall support horizontal scaling to handle an increasing number of concurrent users without performance degradation. The frontend shall be served via a global Content Delivery Network (CDN) to ensure low-latency access for users worldwide. The backend services shall be configured for automatic scaling based on demand. The entire cloud infrastructure shall be defined as code using Terraform. The backend shall be developed using a modular architecture (NestJS). Both frontend and backend codebases shall use TypeScript to enforce static typing.

The primary database shall be configured for automated daily snapshots with a 14-day retention period. Point-in-time recovery shall be enabled for the database, allowing restoration to any second within the backup retention window. In the event of a backend connection failure, the client application shall remain functional for standard, client-side calculations and display a clear, non-disruptive message indicating that cloud features are temporarily unavailable.

User authentication shall be managed by a dedicated Identity Provider (e.g., AWS Cognito, Auth0) that handles secure password storage and supports multi-factor authentication (MFA). A Role-Based Access Control (RBAC) model shall be enforced, ensuring users can only access and modify their own data. All data transmitted between the client and server shall be encrypted using TLS 1.2 or higher. All user data stored in the PostgreSQL database shall be encrypted at rest using AWS Key Management Service (KMS). User-defined formulas shall be executed in a highly secure sandbox (`vm2` on AWS Lambda) with strict timeouts, memory limits, and no access to the network or filesystem. The CI/CD pipeline shall include automated security scanning: Static Application Security Testing (SAST), Software Composition Analysis (SCA), and container vulnerability scanning.

The system shall provide a fully functional scientific calculator with standard arithmetic, trigonometric, and scientific operations. The system shall provide specialized modes for Ohm's Law & Power, Resistor Combinations (Series/Parallel), Resistor Color Code Conversion, and 555 Timer design. The system shall provide a user-extensible framework for users to create, save, manage, and share their own custom calculation modes using a guided interface. The system shall provide a user account system for persisting variables, calculation history, and custom modes. The system shall be implemented as a responsive web application, accessible on modern desktop and mobile browsers. The system shall not be a native mobile application (iOS/Android). The system shall not provide a centralized, public repository or "marketplace" for sharing custom modes. The system shall limit sharing to file-based export and import. The system shall not provide real-time collaboration features between users. The system shall not provide circuit simulation or schematic drawing capabilities.

This document outlines the requirements for an advanced calculator designed for electronics engineers. 1. Core Functionality: - The application will feature a standard scientific calculator interface with a calculation history display. - It will support all basic arithmetic, trigonometric, and scientific functions. - A key feature is the configurable display for engineering notation (e.g., 1.23k instead of 1230) with support for common electronics units (kV, mA, MΩ). - It will include robust memory functions and allow for simple variable assignments (e.g., R1 = 2.2k). 2. Advanced Electronics Features: - Ohm's Law & Power Mode: A dedicated mode where a user inputs any two of Voltage (V), Current (I), Resistance (R), or Power (P), and the calculator automatically computes the other two. - Resistor Combinations Mode: A tool to calculate the total equivalent resistance of a list of resistors in either series or parallel. - Resistor Color Code Mode: A bidirectional converter to find the color bands for a given resistance value (and tolerance) or to find the resistance value from a set of selected colors. - 555 Timer Mode: This mode has been revised for feasibility. - Astable Mode: The user must input the desired frequency, duty cycle, AND the value of one component (RA, RB, or C). The calculator will then solve for the other two. - Monostable Mode: The user must input the desired pulse width AND the value of one component (R or C). The calculator will then solve for the other. 3. User-Extensible Functionality: - The calculator will feature a user-friendly interface for creating custom calculation modes without programming. - Users can define input and output variables, enter the corresponding algebraic formula, and customize the simple UI for their new mode. - An example is creating an 'Op-amp Gain' calculator where a user inputs R_in and R_fb to get the gain. 4. Implementation & Collaboration: - The application should be developed as a cross-platform solution (web, desktop, or mobile) with a responsive design. - A core feature will be the ability for users to save and share their custom-created calculator modes, fostering a collaborative library of tools. - A lightweight scripting engine (like JavaScript or Python) will power the custom formula evaluation.

1. Basic interface and core functionality The main interface would resemble a high-end scientific calculator, with a clear display showing both the current calculation and history. • Standard functions: All basic arithmetic, trigonometry, and scientific functions (log, exp, powers, roots) would be present. • Engineering notation: The display would be configurable to automatically show numbers in engineering notation (1.23×10^3 instead of 1230), with configurable units like kV, mA, or MΩ. • Memory and variables: Robust memory functions allow storing and recalling values. A simple variable assignment feature (e.g., R1 = 2.2k) would help organize complex, multi-step calculations. 2. Advanced electronics features Beyond the standard interface, dedicated modes and buttons would offer common, but complex, calculations with streamlined inputs. Mode: Ohm's law and power Instead of juggling three separate formulas, this mode presents a simple interface to calculate any variable based on the other two. • Input fields: V, I, R, P. • How it works: The user enters any two values and the other two are automatically calculated and displayed. • Example: Enter V=12V and P=50W, and the tool immediately displays I=4.17A and R=2.88Ω. Mode: Resistor combinations This mode simplifies series and parallel resistor calculations. • Input: The user adds resistors to a list (e.g., 2.2k, 1k, 5.6k). • Buttons: A Series button and a Parallel button. • Output: The tool displays the single equivalent resistance. Mode: Resistor color code This feature would convert between resistor values and color codes. • Value to color: Enter a value like 470k and the calculator displays the corresponding color bands and tolerance. • Color to value: The user selects colors from a palette, and the calculator displays the resistance value. Mode: 555 Timer A mode dedicated to the popular 555 timer IC allows users to design circuits without manually looking up formulas. • Astable mode: Input the desired frequency and duty cycle. <<$Change>>The user must also provide a value for one of the three components (RA, RB, or C). The calculator then outputs the necessary values for the remaining two components.<</$Change>> <<$Addition>> Enhancement Justification: The original requirement to output RA, RB, and C based only on frequency and duty cycle is mathematically impossible. The system involves two equations (one for frequency, one for duty cycle) but three unknown variables (RA, RB, C), making it an underdetermined system with infinite solutions. This change makes the requirement feasible by having the user provide a value for one component, reducing the unknowns to two and allowing the calculator to solve for a unique set of values for the remaining components. <</$Addition>> • Monostable mode: Input the desired pulse width. <<$Change>>The user must also provide a value for one of the two components (R or C). The calculator then outputs the required value for the other component.<</$Change>> <<$Addition>> Enhancement Justification: The original requirement to output both R and C based only on the pulse width is mathematically impossible. The formula T = 1.1 * R * C is a single equation with two unknown variables. For any given pulse width (T), there is an infinite set of R and C pairs that satisfy the equation. This change makes the requirement feasible by having the user specify either R or C, allowing the calculator to solve for the single remaining unknown. <</$Addition>> 3. User-extensible functionality The most innovative feature would be the ability for engineers to add custom "modules" or "modes" to the calculator. Custom mode creation • Interface: A simple, guided interface allows users to define a new calculator mode without needing to write a full program. • Step 1: Define variables: The user specifies the input variables and output variables for their formula (e.g., Input: R1, R2, C1; Output: F_cutoff). • Step 2: Enter formula: The user writes the formula using standard algebraic syntax (e.g., F_cutoff = 1 / (2 * pi * R1 * C1)). The formula editor could highlight variables to help prevent errors. • Step 3: Define interface: The user can then customize how the inputs are displayed (text fields, sliders, etc.) and what the buttons or labels should say. Example of user-defined module: Op-amp gain 1. Define mode: Op-amp Inverting Gain. 2. Define variables: o Inputs: R_in (Input Resistor), R_fb (Feedback Resistor). o Output: Gain. 3. Enter formula: Gain = - (R_fb / R_in). 4. Create button: A new button "Op-amp Gain" appears on the calculator, and clicking it brings up the custom interface. The user enters values for R_in and R_fb, and the tool instantly calculates the gain. 4. Implementation considerations • Platform: This could be developed as a cross-platform desktop application (using a framework like Electron), a web application, or a native mobile app for on-the-go calculations. A responsive design would work on devices from smartphones to desktops. • Sharing and collaboration: The ability to save and share custom modes would turn the calculator into a collaborative tool. Engineers could build a library of specialized calculators for specific projects and share them with their teams. • Backend: A lightweight scripting engine (like JavaScript or Python) could be used to process custom formulas and handle the logic for specialized modes.