Probridge- Technical Business Systems Analyst

Trellance LLC•Tampa, FL

About The Position

Established as a separate entity in 2025, ProBridge is a wholly owned subsidiary of Trellance. It evolved from Trellance’s Talent Line of Solutions, leveraging deep industry experience to provide organizations with access to highly skilled technology and finance professionals. ProBridge delivers both expert resources and customized solutions to our clients, helping them scale teams, optimizing operations, and meet their business objectives. Summary: The Technical Business Systems Analyst (TBSA) serves as a client advocate and assumes responsibility for managing the successful delivery of the project. The TBSA owns the translation of business and functional requirements into clear, testable specifications that engineering can build against. This is a client-facing role: the TBSA runs working sessions with client stakeholders, captures decisions, and produces the artifacts that keep business, UX, and engineering aligned throughout delivery of the web-based portal. The role requires no assumptions about specific portal functionality; the TBSA discovers and documents what the system needs to do through structured client engagement. The project follows a hybrid SDLC: waterfall-style planning and phase gates govern project-level scope, milestones, and client signoffs, while development executes in sprints using user stories. Requirements are authored as user stories scoped to the UI page-component level—each story describes a discrete, testable piece of portal functionality (a form section, a data table, a workflow step within a page) rather than an entire feature or epic. The TBSA bridges these two layers, ensuring that project-level requirements decompose cleanly into sprint-ready page-component stories. What Success Looks Like: The client is supported with clear guidance and recommendations on feature design and functionality to help inform decision making. Every page-component user story entering a sprint has acceptance criteria specific enough for a developer to implement and a QA analyst to verify without follow-up questions. Project-level requirements decompose into page-component stories with no gaps or orphaned logic; UX designs and stories stay in sync. Client stakeholders confirm that documented requirements accurately reflect their intent before design or development begins. The decision log is current; no decision older than five business days sits in an unresolved state. Rework caused by ambiguous or missing requirements stays below an agreed threshold (tracked per sprint). Key Deliverables: The TBSA is directly responsible for producing and maintaining these artifacts: Deliverable Description Project-Level Requirements Waterfall-style requirements document defining scope, business rules, and client-approved functional specifications per project phase or milestone. Page-Component User Stories Sprint-ready user stories scoped to individual UI page components (e.g., a form section, data table, workflow step) with acceptance criteria, business rules, required data fields and their database sources, display/validation rules, and data-freshness expectations where sync timing matters. Decision Log Running record of every business/functional decision: options considered, rationale, approver, and date. Feedback Tracker Client feedback items with status (submitted, reviewed, accepted, rejected, revised) and resolution notes. Action Item Summary Clear ownership of action items with ETAs and weekly follow-up to close open items. Session Summaries Written outcomes from every client working session: decisions made, open items, owners, and deadlines.

Requirements

Minimum Bachelor's degree with IT related focus, preferably information systems or systems analysis and design with 5–7+ years as a Business Analyst or Technical Business Analyst, with at least 3 years in a client-facing capacity working with senior business or advisory stakeholders OR a High School diploma or equivalent plus 10+ years as a Business Analyst or Technical Business Analyst, with at least 3 years in a client-facing capacity working with senior business or advisory stakeholders.
Demonstrated ability to translate consultative, domain-heavy discussions into structured, testable system requirements.
Hands-on experience with web-based platforms or enterprise portals and data-driven or rules-based applications.
Strong facilitation skills: able to run a room, keep discussions on track, and drive to decisions.
Strong presentation skills with proven ability to interface with senior executives to explain UX and technology design concepts to drive consensus on design and/or functionality decisions.
Proficiency writing acceptance criteria and business rules at the UI page-component level; experience decomposing project-level requirements into granular, sprint-ready user stories.
Experience working in a hybrid SDLC: waterfall-style project planning with agile sprint execution and user-story-driven development.

Nice To Haves

Domain experience in financial services, executive benefits, life insurance, or advisory platforms.
Background in data mapping and complex business-rule documentation (decision tables, conditional workflows, lifecycle-based logic).
Experience working with distributed or cross-functional delivery teams across multiple time zones.
Comfort working across collaboration tools (e.g., Jira, Confluence, Figma, Teams) while keeping a single governed source of truth.

Responsibilities

Client Working Sessions Develop an understanding of the client’s business model, solutions offered, and program lifecycle in order to effectively translate requirements and provide meaningful recommendations.
Provide proactive recommendations on system behavior, workflows, and user experience based on industry best practices.
Plan, facilitate, and document structured working sessions with client stakeholders, advisors, and subject matter experts with the goal to align on requirements and make decisions.
Surface assumptions, dependencies, and decision points during sessions.
Distribute session summaries with decisions, open items, and owners within one business day.
Requirements & Story Decomposition Author and maintain project-level requirements documents that define scope, business rules, and functional specifications aligned to waterfall phase gates and client sign-off milestones, while ensuring that all documentation is purpose-driven and right-sized for its audience.
Decompose project-level requirements into page-component user stories—each scoped to a discrete UI element (a form section, data table, navigation step, or workflow action within a page)—so that every story is independently implementable in a single sprint.
Write acceptance criteria for each page-component story in a Given/When/Then or equivalent format so they are directly testable by development and QA.
Maintain traceability from project-level requirement to page-component story to UX design artifact, ensuring no logic is lost in decomposition.
Flag conflicting, incomplete, or cross-cutting requirements before they reach development; coordinate with UX when a page-component story spans multiple design states.
Decision & Feedback Resolution Own the decision log: record every decision within 24 hours of the session where it was made.
Track client feedback through its full lifecycle; escalate any item that remains unresolved for more than five business days.
Communicate outcomes and rationale back to stakeholders in writing; do not rely on verbal confirmation alone.
Incorporate decisions directly into the relevant requirements and user stories so documented intent and implementation artifacts remain fully aligned.
UX & Portal Experience Review wireframes and prototypes (e.g., in Figma) against documented requirements before client walkthroughs.
Convert UX decisions into updated functional requirements or acceptance criteria.
Consolidate scattered design-tool feedback into the central feedback tracker.
Technical & Data Collaboration Validate data fields and database sources referenced in page-component stories with engineering; clarify display rules, validation logic, and data-freshness expectations where sync timing matters.
Document conditional logic, business rules, and workflow branching in a format engineering can implement directly (decision tables, pseudocode, or flowcharts).
Identify integration points with internal or third-party systems and document expected inputs, outputs, and error handling.
Serve as the functional reference during development and testing, answer developer and QA questions with documented rationale, not ad hoc opinion.
Documentation & Governance Own and maintain a centralized, structured source of truth for all requirements, feedback, decisions, changes, and approved designs – organized in a way that allows stakeholders to easily reference prior discussions, options considered, and final decisions (by page and functionality).
Ensure only one active version of working documents is in circulation at any time; manage updates through controlled iterations to avoid mid-cycle changes and rework.
Ensure materials are complete and decision-ready before scheduling review meetings.
Reduce meeting dependency by producing documentation clear enough to replace status calls where possible.