Requirement Analysis Framework

How TPL runs discovery at Prime Products Ltd: 15 departments, ~109 employees, ~6–8 weeks, minimal disruption to daily operations. Every method below ends in a concrete artifact stored in this vault. Nothing is “discovered” until it is written down in English (ADR-003) and linked.

1. Discovery process — week-by-week flow

Target: 6 weeks nominal, 8 weeks with buffer (vessel-call peaks and tender deadlines will eat sessions — plan around them, see questionnaire-department-heads.md §seasonality).

Week	Activity	Output
1	Kickoff. CEO all-hands announcement (30 min, Greek), department-head briefing, distribute all-employees questionnaire and management questionnaire. IT questionnaire goes out same day — technical answers gate hardware sizing in ../05-technical/hardware-and-sizing.md.	Communication sent; questionnaires live; response tracking sheet
2	Questionnaires close (all-employees, department-heads, management, IT). First-pass analysis: response heatmap, hotspot list per department. Schedule interviews.	Questionnaire analysis note; interview calendar
2–4	Stakeholder interviews (§2): CEO + executives first, then all 15 department heads, then 2–4 key doers per department flagged by questionnaire hotspots. Roughly 30–40 interviews total, 4–6 per day max.	Interview notes (one file per session)
3–5	Department workshops (§3): half-day per department, prioritized by size and expected AI impact — sales, procurement, logistics/warehouse, finance/accounting first. Small departments may be paired (e.g. HR + administration).	Workshop artifacts: process inventory, pain-point list, wish list
4–6	Process mapping (§4): process-owner questionnaire + mapping sessions for the top ~30 processes company-wide (top 2–3 per department).	One process map file per process, destined for 05-Processes/
6–7	Synthesis. Pain-point quantification (§5), data source inventory (§6), opportunity scoring (§7), AI-readiness scoring (§8). Draft REQ files.	Draft REQ-NNN files; scored use-case list for ../08-ai-portfolio/ai-use-case-pipeline.md
7–8	Validation. Walk drafts back through department heads (1 h each) and management (half-day readout). Corrections applied; requirements move captured → validated.	Validated REQ register; discovery readout deck feeding ../01-strategy/board-presentation-outline.md

Rules of the road:

• No session without an artifact committed to the vault within 24 h.
• Questionnaires are administered in Greek; masters and all committed notes are English.
• Discovery does not stall delivery: quick wins found in weeks 2–4 may enter the pipeline immediately.

2. Stakeholder interview method

Format: 60–90 min, one interviewee (department heads, executives) or max two (paired doers from the same team). Two TPL people when possible: one leads, one takes notes.

Structure (90-min version — compress proportionally):

Segment	Min	Content
Framing & consent	5	Purpose, confidentiality, recording consent (see below)
Role & day-in-the-life	15	What they do, time split, tools
Deep dive on questionnaire hotspots	30	Their own flagged answers — repetitive work, bottlenecks, Excel/email workflows
Process walk-through	20	Pick 1–2 processes, walk them end-to-end (feeds §4)
AI attitudes & wishes	10	Hopes, fears, “top 3 wishes” revisited verbally
Wrap	10	Confirm follow-ups, name candidate process owners and champions

Recording & consent: ask explicitly at the start; audio recording only with verbal consent noted in the interview file. Recordings are working material, deleted after notes are finalized — they are never committed. If consent is declined, notes only.

Capture: every interview becomes one file from the interview-notes template (type: interview, data_sensitivity: high). Sessions are conducted in Greek; notes are written in English at capture time — do not accumulate Greek drafts. Keep an original Greek phrase in parentheses only where the exact domain wording matters (e.g. a SoftOne screen name or trade term). Refer to people by role, not name, unless the name is operationally necessary.

3. Department workshop format

Format: half-day (4 h), whole department or its core team (5–10 people), whiteboard or Miro-style board, one TPL facilitator + one scribe. Department head present but explicitly asked to let doers speak first.

Time	Block	Artifact produced
0:00–0:20	Framing: transformation goals, what happens with the output, “nobody is being timed-and-motioned”	—
0:20–1:20	Process inventory: list everything the department does; dot-vote top 10 by time consumed	Ranked process inventory (top 10 with rough weekly volumes)
1:20–2:20	Pain-point harvest: silent brainstorm on stickies, cluster into the five categories (§5)	Categorized pain-point list
2:20–2:40	Break	—
2:40–3:30	Deep dive: map the #1 process live as SIPOC + swimlane (§4)	Draft process map
3:30–4:00	Wish list & readiness: “if a tireless assistant joined tomorrow, what would you hand it?”; quick self-assessment against the readiness dimensions (§8)	Automation wish list; readiness self-score

All artifacts are transcribed into the department’s file under ../04-departments/_index.md within 24 h; the draft process map becomes a process file (§4).

4. Process mapping method

Two levels, both lightweight:

1. SIPOC (Suppliers, Inputs, Process (5–7 steps), Outputs, Customers) — a table, five minutes to sketch, forces scope agreement.
2. Simple swimlane — one lane per actor/system, drawn in Mermaid inside markdown so it renders in Obsidian and GitHub and diffs cleanly. No BPMN tooling.

flowchart LR
  subgraph Sales
    A[Receive RFQ email] --> B[Check stock in SoftOne]
  end
  subgraph Procurement
    B --> C{In stock?}
    C -- no --> D[Request supplier quote]
  end
  subgraph Sales2[Sales]
    C -- yes --> E[Issue quotation]
    D --> E
  end

Storage: one process per file, kebab-case (e.g. provisioning-order-to-delivery.md), frontmatter type: process. Files are drafted here during discovery and move to 05-Processes/ when that folder is created (per CLAUDE.md, created when the first real content arrives — discovery will be that trigger). Each file carries: SIPOC table, swimlane, and the process-owner questionnaire answers (volumes, duration, error rate, exceptions, approvals, double entry, waiting points).

5. Pain-point analysis

Categorization — every pain point gets exactly one primary category:

Category	Signature	Typical AI/automation response
Repetitive	Same steps, high frequency, low judgment	Automate outright or agent-assist
Error-prone	Rework, corrections, disputes	Validation, extraction, cross-checking
Waiting / bottleneck	Work queues behind a person, approval, or information	Routing, escalation, pre-work by agent
Knowledge-gap	Only one person knows how; onboarding is slow	Knowledge capture into the vault + RAG assistant
Visibility-gap	Nobody can see status/stock/margin without asking around	Reporting, dashboards, query assistant

Quantification — for every pain point score the annual cost:

Annual cost ≈ frequency (occurrences/year) × time per occurrence (h) × loaded hourly cost (€) + error cost (rework hours + hard cost of errors, €/year)

Use a default loaded rate band (assumption — to validate in discovery with Finance) rather than per-person salaries. Precision target: order of magnitude, not payroll accuracy. Record frequency/time/error inputs explicitly so scores can be re-run.

6. Data source identification

For each mapped process, inventory every data source touched:

Field	Values
Source	SoftOne module/screen, M365 (Outlook, Teams, SharePoint/OneDrive, Excel), e-shop platform, other system, paper
Content	What data lives there (e.g. price lists, IMPA codes, chart catalog, HACCP records)
Format	Structured (DB/ERP), semi-structured (Excel), unstructured (email, PDF, scans, paper)
Owner	Role who maintains it
Freshness & size	Update cadence, rough volume
Duplication	Where the same data is re-entered (flag for §7 scoring)

This inventory aggregates into the data source inventory feeding ../05-technical/rag-and-data-pipeline.md and the integration design in ../05-technical/integrations-m365-softone.md.

7. Automation opportunity scoring model

Every candidate (from pain points, wish lists, interviews) is scored 1–5 on six dimensions:

Dimension	Weight	1	3	5
Frequency	20%	Yearly/ad-hoc	Weekly	Many times daily
Volume (items or hours touched)	15%	Trivial	Moderate	Large share of a role’s time
Rule clarity	20%	Pure judgment	Judgment with clear guardrails	Deterministic rules
Data availability	20%	Paper/tribal knowledge	Semi-structured (Excel/email)	Structured & accessible (SoftOne/M365 API)
Risk if wrong (inverted)	15%	Safety/regulatory/financial harm	Recoverable with rework	Trivially reversible
Human-in-loop need (inverted)	10%	Every output needs expert review	Spot-check	Fully autonomous acceptable

Score = Σ(dimension × weight), range 1.0–5.0. Interpretation: ≥4.0 fast-track candidate; 3.0–3.9 pipeline backlog; <3.0 park (revisit after data/process improvements). Scores and inputs go with each candidate into ../08-ai-portfolio/ai-use-case-pipeline.md. Note the risk and human-in-loop dimensions are inverted: high risk scores low. CBRN/hazmat, safety-equipment certification, and food-safety (ISO 22000) processes will typically score low on risk by design — that is correct behavior, not a model flaw.

8. AI-readiness scoring per department

Five dimensions, scored 1–5, presented as a radar per department in its file under ../04-departments/_index.md:

Dimension	1	3	5
Data quality	Paper & personal Excel, inconsistent	Shared files, mostly consistent	Clean structured data in SoftOne/system of record
Process documentation	Nothing written, tribal	Partial, outdated docs	Current, followed procedures (ISO-audited processes often score high here)
Digital adoption	Resists systems, prints emails	Uses ERP/M365 as required	Actively exploits tooling, self-serve
Champion strength	No candidate champion	Willing but junior/overloaded	Credible, enthusiastic champion identified
Change appetite	Threatened/hostile	Neutral, wait-and-see	Actively asking for AI

Scoring is done by the TPL team from questionnaire + workshop evidence, then sanity-checked against the department’s self-score from the workshop. Readiness gates sequencing: a high-opportunity/low-readiness department gets enablement work (data cleanup, documentation, training) before agents.

9. Cross-cutting requirement capture

Beyond process-level needs, discovery must explicitly capture these categories — each becomes its own REQ where confirmed:

• Integration requirements: every needed touchpoint with SoftOne (which modules, read vs write, Soft1 Web Services availability — see questionnaire-technical-it.md), M365 (Graph API scopes: mail, files, Teams), and the e-shop platform. Detail lands in ../05-technical/integrations-m365-softone.md.
• Reporting requirements: every report produced or wished for — source data, audience, cadence, current effort. Cross-check management answers (“reports I want but don’t get”) against what departments already produce; the gap is usually the first BI win.
• Security requirements: data classification needs, access boundaries (e.g. margins visible to whom), customer confidentiality (shipping clients are sensitive about vessel movements), GDPR for HR/customer data, on-prem-only data classes. Feeds ../05-technical/security-and-operations.md.
• Training requirements: per role cluster — comfort level, language (Greek-first), format preferences. Feeds ../02-program/change-management-and-training-plan.md.
• Change-management requirements: named resistance points, roles whose work changes most, communication needs, union/works-council considerations if any (assumption — to validate in discovery).
• Technical infrastructure requirements: anything discovery reveals that constrains the on-prem LLM deployment — server room, power/cooling, bandwidth, endpoint fleet. Feeds ../05-technical/hardware-and-sizing.md and ../05-technical/architecture-overview.md.

10. Department requirement capture — mandatory fields

Every department capture, before it can produce REQ files, must fill:

Field	Description
Department & roles affected	From the 15-department list; roles only, no names
Need statement	One sentence, business language (“Sales needs X so that Y”)
Source evidence	Links to questionnaire analysis / interview notes / workshop artifact
Process link	The process file(s) it belongs to
Pain category & quantification	§5 category + annual-cost estimate with inputs
Data sources involved	§6 inventory rows
Opportunity score	§7 score with per-dimension values
Dependencies	Systems, integrations, other REQs
Cross-cutting flags	Integration / reporting / security / training / change / infra (§9)
Validation	Who validated it (role), date

Formal capture uses the vault’s requirement template. Every validated need becomes a REQ-NNN file in 02-Requirements/ with a row added to ../../02-Requirements/_index.md in the same change — status starts at captured, moves to validated after the week-7–8 readout. Requirements that are AI/automation opportunities additionally enter the use-case pipeline with their score.