As a Systems Engineer, my role was perform comprehensive Requirements Traceability. I translate complex external tender specifications into actionable internal workflows.

1. The Methodology: Mapping the Layers

The core challenge in project delivery is translation. A C-level executive wants to know about “a reliable billing system for a shopping center,” while the engineer needs to know if they require “Class 0.5 accuracy” or “NMI approval.” To solve this, I mapped requirements across three execution layers:

  1. Business Layer: Focus on project type (e.g., Tenant Billing, Power Quality Analysis), budget, and time estimation.
  2. Project Layer: Physical constraints and compliance (e.g., Panel vs. DIN rail, NMI certification).
  3. Hardware Layer: The granular technical specifications.

The challenge:

Bringing together multiple layers of internal company and client requirements.

2. The fundamental disconnect arises because every department operates as an isolated core, mistaking their specific internal constraints for the project’s entire reality. Engineering often confuses “What is Necessary?” with merely “What is Feasible?” based on the current catalogue, focusing on how it works rather than why it matters. Sales falls into a similar trap, mistaking “What solves the problem?” for “What is on the shelf?” to hit a quarterly target, while Management translates “Strategic Vision” into rigid “Current Policy,” asking “What can we afford?” instead of the critical question: “What can we not afford to miss?” This collective myopia ensures that the client’s actual need is filtered out before it ever reaches the execution stage.

The Situation:

Mistake the question “What needs to be be done?” for “What can WE do?”

3. The immediate complication of this misalignment is a destructive friction loop: the unhappy customer demands expanded scope and remediation to fix the gap, while the company, under margin pressure, attempts to cut losses by offering less. This adversarial dynamic benefits no one. Paradoxally, a far superior outcome is early rejection. If the customer identifies immediately that the solution is a “poor fit,” we achieve the Minimum Loss scenario. It is infinitely cheaper to lose a proposal at the concept stage than to manage the operational drag of a deployed project that fails to meet the business need.

Complication

An unhappy customer and/or a loss instead of a profit

4. communication platforms designed specifically to connect teams, the “Translation Gap” remains the single most common point of failure. Why? The uncomfortable truth is that we are trying to solve a cultural problem with technological tools. Culture is the “operating system” of a group, and it is notoriously resistant to updates.

Beyond culture, we face the inevitable result of modern complexity: Hyper-Specialization. Every department—whether it is Legal, Logistics, Finance, or tech-has evolved into a domain so deep that true expertise requires total immersion. It is no longer possible for an outsider to fully grasp another group’s workflow nuances. We have effectively become islands of expertise, separated by the very depth of knowledge required to perform our specific roles.

Question:

What are the main reasons for Brocken’s communication?

Recommendation: The Dynamic Capability: Modular Scalability I designed the architecture for Dynamic Capability, adopting the same philosophy used in PLC Step Programming (SFC). Just as a control engineer can insert a new “step” into a sequence without rewriting the entire logic block, this structure allows for seamless expansion. If a new project type emerges—such as “EV Charging Integration”—or a new regulatory question arises, I do not need to refactor the application’s core code. I simply inject a new node into the JSON structure. This modularity ensures the system remains a “living” tool, capable of evolving alongside market demands without accruing technical debt.

The Architecture: Firebase & Google Sheets For the software stack, I prioritized accessibility over complexity. I utilized Firebase for the backend infrastructure, but for the data management layer—the “Administrative Frontend”—I chose Google Sheets. It
is the path of least resistance. It transforms a complex JSON editing task into a simple spreadsheet entry. This setup allows for rapid iteration: I can add an additional question
or modify a logic path in the Sheet, and by simply clearing the app’s current state and triggering a reload, the system instantly fetches and compiles the latest decision tree. No deployment pipelines, no code commits—just immediate, live updates.

Firebase

  • Why: Firebase provides a serverless backend, real-time database, and hosting for static files. It’s very beginner-friendly and requires minimal setup.
  • How:
    • Use Firestore for storing the product logic (e.g., a decision tree).
    • Use Firebase Hosting for the frontend.
    • Use Firebase Functions if any logic needs to be executed server-side.

Firebase offers a free tier called the Spark Plan, which is suitable for small projects and getting started.

  • Go to Firebase Console.
  • Click “Add Project”.
  • After the project is created, go to the “Project Settings” (gear icon in the top left).
  • Under “Your Apps”, click the Web App icon (</>).
  • Register your app with a name, then click Register App.
  • In the Firebase Console, go to “Build” > “Firestore Database”.
  • Click “Create Database”.
  • Choose a start mode:
    • Test Mode: All users can read/write data (use for development). as beginner

Firestore Database

  • Start Collection Collection Name: Enter a name for the collection, e.g., Questions.
  • Add the First Document
    • Document ID: Use a custom ID to identify the question. For example, start with Q1.
    • Add Fields:
      • id: 1 (Unique identifier for the question).
      • question: "What is mounting type?".
      • DIN Rail: Q11 (Points to the next question when “DIN Rail” is selected).
      • Panel: QQ12 (Points to the next question when “Panel” is selected).

above is manual and slow so there are different options I want to use CLI
npm install -g firebase-tools
firebase login

The firebase firestore:import command is not natively supported in the Firebase CLI for Firestore. so we have 2 options 1)Admin SDK 2)API and e.g postman
npm install firebase-admin : it creates node packages and obviusly required key.

Steps to Generate a Service Account Key for Firebase Admin SDK
Place it in the same directory as your Node.js script (importFirestore.js).
Go to Firebase Console:
Go to Project Settings (gear icon in the sidebar).
Select the Service Accounts tab.
Generate a New Private Key:
Click Generate New Private Key.
Save the Key File: Rename the file to something memorable, like service-account-key.json.

with the help of chatGPT I write simple code to import question rather than write them one by one

Decision Tree
  • What is the mounting type? (Din-Rail or Panel Mount)
  • What phase does the system use? (Single Phase or Three Phase)
  • Is a National Meter Identifier (NMI) required? (Yes or No)
  • What communication protocol is needed? (RS485, Modbus, Ethernet)
  • Is memory or data logging required? (Yes or No)
  • What is the voltage range of the system? (Low Voltage, Medium to High Voltage, DC Metering.)
  • What is the current measurement method? (Less than 100A or More than 100A)
  • Is advanced functionality required? (Harmonics, Power Quality)
  • What is the accuracy class required? (Class 0.5, Class 1,Class 2 )
  • Does the meter need certification for regulatory compliance? (Yes or No)

Leave a comment