I translate business objectives into requirements, API contracts, and data workflows for AI-native SaaS products, then trace every line back to why it matters.
↓ Download CV (PDF)I make sure engineering builds the right thing, and that stakeholders can see, trace, and verify why each piece exists. I sit between product/leadership and engineering, translating "what the business needs" into specs a dev team can build from without guessing.
From the PFE report's introduction: the fragmented, manual-handoff tooling landscape most B2B GTM teams navigate, contrasted with the unified platform approach.
Fragmented tooling landscape vs. unified platform approach (click to view full size).
| ID | Requirement | Business Objective | Test Case |
|---|---|---|---|
| FR-014 | System shall route AI queries through a fallback chain if the primary LLM provider times out. | Maintain 99% uptime for client-facing AI features | TC-014 |
| FR-021 | System shall enforce row-level tenant isolation on all client data queries. | GDPR compliance across EU client base | TC-021 |
| FR-033 | System shall log anomaly-detection flags with severity tier for reviewer triage. | Reduce manual QA review time by 30% | TC-033 |
Illustrative reconstruction for portfolio purposes: client-confidential values generalized; structure and role reflect the actual engagement.
| Monolith | Federated SOA (chosen) | Microservices | |
|---|---|---|---|
| Team fit | 1 team | Small team, per-service ownership | Requires dedicated per-service teams |
| Failure isolation | One crash affects all domains | Service crash stays within one domain | Partial failures complex to diagnose across network |
| Data security | Shared schema | Schema isolation per context | Independent databases |
Rationale: bounded-context separation (DDD) without microservices' distributed-transaction overhead, fitting a small team and a tight cost ceiling.
| Why Scrum | Lean-team adaptation |
|---|---|
| Product scope shifted with client feedback | Founder acted as Product Owner and Scrum Master; direct client meetings, Jira backlog, sprint priorities |
| Features needed calibration on real usage | 3× weekly stand-ups; source on GitHub, async coordination on Slack |
| External API constraints surfaced late | Formal backlog, sprint backlog, Definition of Done, and RTM maintained throughout |
| KPI category | Metric | Target |
|---|---|---|
| Functional | Content approval rate | High rate, strong brand alignment and prompt quality |
| Operational | Signal freshness delay | Minimize delay between signal capture and dashboard |
| Quality | Tenant isolation incident count | Zero cross-tenant access events |
| Economic | LLM cost per tenant | Keep the large majority of requests within free-tier quotas |
From the PFE report's functional analysis chapter, one use case diagram per bounded-context service.
Portal, identity and core management (click to view full size).
Tropicc, LinkedIn content generation (click to view full size).
Oceanss, go-to-market intelligence (click to view full size).
To-be process models from the PFE report, modeling actor responsibilities, decision points, and cross-service data movement.
To-be LinkedIn content generation process (click to view full size).
To-be GTM intelligence workflow, collaboration diagram (click to view full size).
Architecture diagram from the InterQ report (click to view full size).
Entity-relationship diagram from the InterQ report (click to view full size).
Use case diagram from the InterQ report (click to view full size).
Illustrative reconstruction for portfolio purposes, reflecting the actual delivered workflow.
Product backlog for MyVioo (PFE Report Table 2.2) — 8 features broken into user stories with priority and story-point estimates. End-of-studies project, co-authored with a teammate; artifacts reflect my requirements and modeling contribution.
| ID | Feature | User Story Description | Priority | Pts |
|---|---|---|---|---|
| F1 | Pack Purchase to Become a Partner | As a user, I want to be able to purchase a pack to become a partner and own channels. | High | 5 |
| F2 | Authentication | As a user, I want to be able to register and log in MyVioo securely. | High | 8 |
| F3 | User Account Management | As a user, I want to be able to manage my account settings and update my personal information. | Medium | 5 |
| F4 | Channel Management | As a partner, I want to be able to create and manage my own channel on MyVioo. | High | 8 |
| F5 | Content Management | As an admin, I want to be able to upload, organize, and manage video content on my channel. | High | 8 |
| F6 | Events Management | As an admin, I want to be able to create and manage events for users to participate in. | Medium | 3 |
| F7 | Video Search | As a user, I want to be able to search for videos based on keywords or specific criteria. | Low | 5 |
| F8 | Content Interactions | As a user, I want to be able to like and comment the videos. | Medium | 3 |
MyVioo global use case diagram — 5 actors (Super Admin, Partner, Channel Admin, Member, Speaker), from the PFE report's functional analysis chapter (click to view full size).
| Description of Use Case: Purchase Pack (PFE Report Table 4.3) | |
|---|---|
| Actors | User (All Actors), Super Admin (validation) |
| Precondition | The user has the website's link. |
| Main flow | 1. User selects a pack to purchase in the pricing section inside the One Page. 2. User selects a payment option or initiates payment process. 3. System presents payment interface, prompting user to enter payment details. 4. User provides necessary payment information (credit card or transfer proof). 5. System processes payment, verifies validity, and notifies user of transaction status. |
| Postconditions | User successfully completes payment process, becomes a partner, and gains features according to the pack plan purchased. |
Sequence diagram and functional test case from the MyVioo PFE report. The test case reflects CT_REGISTER_001 from the partner registration validation suite.
Purchase Pack sequence diagram — Bank Card and Transfer alternative flows, 16 steps across User, One Page, Server, Payment, and Super Admin (click to view full size).
| Field | Value |
|---|---|
| Test Case ID | CT_REGISTER_001 |
| Feature | Partner Registration (Pack Purchase via Wire Transfer & Super Admin Approval) |
| Precondition | User visits application; email address does not exist in system; Super Admin approval required. |
| Steps | 1. Select currency (EUR/TND/USD) & monthly payment plan. 2. Select wire transfer payment method and attach transfer proof. 3. Complete partner registration form (company name, legal status, contact info, billing address, legal docs RNE/PATANTE/tax exemption, password). 4. Submit form; Super Admin receives and approves registration command. |
| Expected result | Registration completed successfully; client added to users table and assigned Partner role upon Super Admin approval. |
| Status | Success |
A self-directed, solo-founder BA engagement: the full requirements-to-architecture lifecycle on an original product, taken from a raw product-vision document to a buildable, traceable MVP specification, the same discipline practiced at Wavess but fully public. Twelve linked artifacts, 104 requirements each traced to a business objective and a test case, 8 Architecture Decision Records, and 14 user stories, all benchmarked against Hevy, Strong, Fitbod, and Tracked. Differentiated by real-time per-muscle volume tracking (MEV/MAV/MRV) and multi-method progressive overload detection.
| Artifact | Key output |
|---|---|
| Charter | Business objective, scope (in/out), success criteria: artifacts must be handoff-ready and open questions must be surfaced, not silently resolved. |
| Elicitation Plan | 3 stakeholder groups mapped by power/interest; techniques matched per group (competitor-review mining, screened surveys, technical feasibility workshops). |
| Gap Analysis | Benchmarked against Hevy, Strong, Fitbod & Tracked. Confirmed real-time per-muscle volume tracking as the strongest surviving differentiator once overstated claims were corrected. |
14+ open questions logged and tracked across phases rather than resolved by assumption, each tied to the phase and decision-owner that will close it.
9 processes specified at Level 1–2 (P0–P5, plus the P1.1–P1.3 sub-processes) from structured BPMN specs, pools, lanes, gateways, and business rules written out before drawing, plus a 10th process (Free-to-Pro Upgrade) added later once the subscription lifecycle needed its own diagram. 36 business rules extracted in total. Four are rendered below.
P1: Live Workout Session Logging. The core differentiator loop: set entry → RIR-weighted volume calculation → real-time feedback → overload detection (click to view full size).
P1.2: Progressive Overload Detection. Fully automated sub-process: four independent progression checks (weight/rep/RIR/form), then a stagnation counter that raises yellow (4+ sessions) or red (6+ sessions) flags (click to view full size).
P2: Authentication. Session/token validation, OAuth and email/password paths, first-time vs. returning-user routing (click to view full size).
Free-to-Pro Upgrade & Subscription Lifecycle. Added outside the original P0–P5 inventory once ADR-002 (billing model) needed a diagram: trial/plan choice, payment handshake, and four lifecycle chains (renewal, grace, cancellation, refund) (click to view full size).
| Artifact | Key output |
|---|---|
| Requirements Catalog & RTM | 92 functional + 12 non-functional requirements (104 total), each traced to one of 3 business objectives, consolidating the 36 BPMN business rules into requirement form. |
| Use Cases & User Stories | 14 value-slice user stories covering all 104 requirements (orphan-checked), plus 2 formal use cases for the exception-heavy flows and a use-case diagram spec. |
Full traceability chain worked end to end for FR-SET-06 (real-time per-muscle volume feedback): business objective → BPMN task/rule → user story acceptance criteria → data entity → governing ADR → UAT test case, with nothing left implicit.
| Artifact | Key output |
|---|---|
| Data & System Analysis | 6-context bounded-context map, entity-relationship model, and 5 API contract sketches. |
| Architecture Decision Records | 8 ADRs (sync conflict policy, billing/entitlement, auth providers, offline-first architecture, volume as derived state, contribution-score governance, backend stack, deferring the AI coach), honestly marked Accepted vs. Proposed rather than all treated as settled. |
| Prioritization & Roadmap | Weighted scoring (Value/Urgency/Risk/Dependency) applied to the 14 stories, a Jira-style backlog, a dependency-respecting wave plan, and an ordered MVP cut line. |
| UAT Plan | 7 acceptance test cases for the critical criteria, with entry/exit criteria and roles, closing the RTM's Test Case ID column. |
A real trade-off caught mid-analysis: platform in-app-purchase trials generally require a card on file, which contradicts the product doc's "no payment required" 7-day trial. Rather than quietly keep the assumption, ADR-002 surfaced both honest paths and flagged the choice as a founder decision.
Click outside the image, press Esc, or use the ✕ to close