Title of Position: Technical Business Systems Analyst

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 sign-offs, 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-componentuser storyentering 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.

Responsibilities

1. Client Working Sessions

• Develop an understanding of the client's business model, solutions offered, and program lifecyclein order toeffectively translate requirements and provide meaningful recommendations.
• Provide proactive recommendations on system behavior, workflows, and user experience based onindustrybest 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.

2. 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.

3. 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.

4. 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.

5. 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 canimplementdirectly (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.

6. 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).
• Ensureonly 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.

Required Qualifications

• MinimumBachelorsdegree with IT related focus, preferably information systems or systems analysis and designwith5-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 stakeholdersORa High Schooldiplomaor equivalentplus 10+ yearsas 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.
• Domainexpertiseinlife insurance,executive benefits, or advisory platforms.

Preferred Qualifications

• 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.