Forward Deployed Engineer 101: Translating Mission Needs into Technical Scenarios (User Stories, Acceptance Criteria)

Translating Mission Needs into Technical Scenarios (User Stories, Acceptance Criteria)

Translating Mission Needs into Technical Scenarios (User Stories, Acceptance Criteria)

What This Is

As a Forward Deployed Engineer (FDE), your job is to turn vague mission needs—like “we need better threat detection” or “our disaster response team needs real-time logistics data”—into actionable technical requirements. This isn’t just about writing user stories; it’s about bridging the gap between operators (who know the mission) and engineers (who build the solution) in high-stakes, constrained environments. Example: You’re deployed to a classified site where a cyber team needs an ML model to flag anomalous network traffic, but the model must run on-premise with no internet access, limited compute, and strict ATO (Authority to Operate) requirements. Your user stories and acceptance criteria must account for these constraints before a single line of code is written.

Key Terms & Concepts

• Mission Thread: A step-by-step narrative of how a user (e.g., a soldier, analyst, or first responder) interacts with a system to achieve a goal. Used to uncover hidden requirements (e.g., “The user must authenticate via CAC card before accessing the dashboard”).
• Ask vs. Infer: The customer’s stated request (“We need a dashboard”) vs. the actual need inferred from data/mission context (“They need to correlate sensor data in <2 seconds to avoid missile strikes”).
• Acceptance Criteria (AC): Specific, testable conditions that must be met for a user story to be “done.” Written in Given-When-Then format (e.g., “Given a user with a valid CAC, when they submit a query, then results return in <500ms”).
• Non-Functional Requirements (NFRs): Constraints like latency, security, or compliance that aren’t features but are mission-critical (e.g., “Must run on RHEL 7 with FIPS 140-2 validated crypto”).
• Spike Story: A time-boxed research task to answer a technical unknown (e.g., “Can we run TensorFlow Lite on the customer’s ARM-based edge devices?”). Used to de-risk work before committing to a solution.
• ATO (Authority to Operate): The formal approval process for deploying software in government/defense environments. Your AC must align with ATO controls (e.g., “All logs must be retained for 90 days per NIST 800-53”).
• Air-Gapped Deployment: Deploying software in a network with no internet access. Requires offline dependency management (e.g., pip download + pip install --no-index), physical media (USB drives), and manual approval chains.
• Bastion Host: A hardened jump server used to access secure environments. You’ll often SSH into this first (ssh -J user@bastion user@internal-server) to debug customer issues.
• Data Provenance: Tracking the origin and lineage of data (e.g., “This sensor data comes from a classified source and cannot leave the network”). Critical for compliance and AC.
• Technical Debt Story: A user story to address shortcuts taken under pressure (e.g., “Refactor the data pipeline to handle schema drift”). FDEs must balance speed with sustainability.
• Customer Proxy: A role (often an FDE) who translates between the customer and engineering team. Must speak both “mission” and “tech” fluently.
• Chaos Engineering for AC: Intentionally breaking things to validate AC (e.g., “If the database fails, does the app gracefully degrade?”). Use tools like Chaos Monkey or custom scripts.

Step-by-Step / Field Process

1. Discovery: Map the Mission Thread

Action: Shadow the end user (e.g., a cyber analyst, drone operator, or logistics coordinator) and document their workflow in their own words. Ask: - “Walk me through your last mission where this system failed.” - “What’s the worst-case scenario if this doesn’t work?” - “What’s your current workaround?”

Tools/Commands:
- Whiteboard session (physical or digital, e.g., Miro/Excalidraw).
- Voice memos (record interviews with permission; transcribe later).
- Quick Python script to validate assumptions (e.g., df.describe() to check data quality).

Example Output:

Mission Thread: “As a cyber analyst, I monitor network traffic for anomalies. When I see a spike in DNS queries, I manually cross-reference with threat feeds. If it’s a known IOC, I escalate to the SOC. If not, I run a deeper scan, which takes 20+ minutes.”

2. Translate to User Stories

Action: Break the mission thread into epics (big goals) and user stories (small, actionable tasks). Use the template:

As a [role], I want [feature] so that [mission outcome].

Example:
- Epic: “Automate threat detection for cyber analysts.” - User Story: “As a cyber analyst, I want the system to flag DNS anomalies in real-time so that I can investigate threats before they escalate.” - Spike Story: “As a developer, I need to determine if the customer’s SIEM can ingest our model’s output via syslog.”

Field Tip: Avoid “As a user” – be specific (e.g., “As a JTAC operator”).

3. Write Acceptance Criteria (AC)

Action: For each user story, define testable AC in Given-When-Then format. Include NFRs.

Example:

User Story: “Flag DNS anomalies in real-time.” - AC1: Given a network traffic feed, when DNS queries exceed 1000 QPS, then the system generates an alert within 5 seconds.
- AC2: Given a user with “Analyst” role, when they view the dashboard, then they see a list of active alerts sorted by severity.
- AC3: Given a deployment in an air-gapped environment, when the model is updated, then it must be signed with the customer’s GPG key.
- AC4: Given a database failure, when the system restarts, then it recovers without data loss (NFR).

Tools:
- Gherkin syntax (for automated testing with Cucumber/Behave).
- Confluence/Jira (to document AC with the customer).

4. Validate with the Customer

Action: Walk the customer through the user stories and AC in their language. Ask: - “Does this match how you’d use the system?” - “What’s missing?” - “What’s a dealbreaker if we don’t include it?”

Field Tip: Use “show me” instead of “tell me.” Demo a prototype (even a mockup) to uncover gaps.

5. De-Risk with Spikes

Action: For unknowns, write a spike story and time-box it (e.g., 2 days). Example:

Spike: “Determine if we can run our model on the customer’s NVIDIA Jetson devices.” - Tasks:
- ssh into the device (ssh [email protected]).
- Check specs (lscpu, nvidia-smi).
- Run a benchmark (python benchmark.py --model model.tflite).
- Output: “Yes, but we need to quantize the model to 8-bit to meet latency requirements.”

6. Iterate with Feedback Loops

Action: After deployment, observe users and refine. Example: - Problem: Analysts ignore alerts because they’re too noisy.
- Fix: Add AC: “Given 1000 DNS queries, when the system flags an anomaly, then the false positive rate must be <5%.”

Common Mistakes

FDE Interview / War Story Insights

1. The “Scope Creep” Trap

Scenario: You’re on-site during a go-live week. The customer demands a new feature (“We need to integrate with System X”) that wasn’t in the original scope. The PM is pressuring you to “just make it work.” How to Respond:
- Ask: “What’s the mission impact if we don’t do this?” (Often, it’s not as urgent as they claim.) - Propose: “We can spike this in 2 days to assess feasibility, but it’ll delay the current release.” - Document: “Let’s add this to the backlog and prioritize it for the next sprint.” Why: FDEs must balance speed with sustainability. Never let a customer derail a mission-critical release.

2. The “Classified Data” Surprise

Scenario: You’re building a data pipeline and discover mid-development that the customer’s data is classified. Your current solution (e.g., cloud-based processing) is now a non-starter.
How to Avoid:
- Ask early: “What’s the classification level of the data?” (Even if they say “unclassified,” verify.) - AC Check: “Given classified data, when the pipeline runs, then no data leaves the secure enclave.” Field Tip: Always assume data is sensitive until proven otherwise.

3. The “Works in Dev, Fails in Prod” Nightmare

Scenario: Your model works perfectly in your lab but fails in the customer’s air-gapped environment because of missing dependencies.
How to Prevent:
- AC: “Given an air-gapped environment, when the model is deployed, then it must run without internet access.” - Spike: Test in a VM that mimics the customer’s environment (e.g., docker run --network none).
Interview Question: “How would you validate a deployment in an air-gapped environment?”

Quick Check Questions

1. You’re writing AC for a disaster response app. The customer says, “It needs to be reliable.” What’s your next step?

Answer: Ask, “What does ‘reliable’ mean to you?” Then translate to measurable AC (e.g., “99.9% uptime during a 72-hour mission” or “Graceful degradation if the database fails”).
Why: “Reliable” is subjective; AC must be testable.

2. You’re deploying a model to a classified network. The customer’s ATO requires all software to be signed. What’s your first step?

Answer: Add AC: “Given a deployment, when the model is installed, then it must be signed with the customer’s GPG key.” Then spike the signing process (e.g., gpg --sign model.tar.gz).
Why: ATO requirements are non-negotiable; address them early.

3. The customer insists on a feature that violates their own security policy. How do you respond?

Answer: Say, “Let’s document this as a risk and escalate to your security team. If they approve, we’ll add it to the backlog.” Never bypass security for speed.
Why: FDEs are guests in the customer’s environment; respect their rules.

Last-Minute Cram Sheet

1. User Story Template: As a [role], I want [feature] so that [mission outcome].
2. AC Format: Given [context], when [action], then [result].
3. Spike Story: Time-boxed research (e.g., “Can we run X on Y?”).
4. NFRs: Latency, security, compliance, uptime (e.g., “Must run on RHEL 7”).
5. Air-Gapped Checklist:
6. Offline dependencies (pip download + pip install --no-index).
7. Physical media (USB drives, DVDs).
8. Manual approval chains (ATO, IAM).
9. ATO Acronyms:
10. ATO: Authority to Operate.
11. ACO: Approval Chain Officer.
12. IAM: Identity and Access Management.
13. Field Commands:
14. Check network: ping, traceroute, nc -zv <host> <port>.
15. Check system: lscpu, free -m, df -h.
16. Debug logs: journalctl -u <service> -f, tail -f /var/log/syslog.
17. ⚠️ Always test in the exact customer environment – what works in your lab will break behind their firewall.
18. ⚠️ Never assume data is unclassified – ask early and often.
19. ⚠️ If the customer says “just make it work,” push back – document risks and tradeoffs.