A Practical Guide to Uncovering Hidden Requirements in B2B Systems

1. A Failed First Attempt

During a requirement interview for a city‑level trading center upgrade, the client asked for a simple "random expert selection" feature. After implementation, users complained about repeated selections and perceived unfairness, revealing that the request only scratched the surface of deeper needs.

2. Iceberg Model of Requirements

Inspired by the McGovern Iceberg Model, only about 10% of needs are voiced; the remaining 90% lie hidden beneath the surface, especially in rule‑dense B2B domains where compliance drives many implicit requirements.

Customer‑stated need → Visible (10%)<br/>Unspoken needs → Hidden (90%)

3. Four‑Dimensional Exploration Method

The author distilled four effective dimensions for uncovering hidden needs.

Dimension 1: Process Reconstruction (Task Analysis)

Observe users performing their actual workflow at the workstation, noting pauses, workarounds, mental checks, and manual compensations. Example: an operator copied the random‑selection list to Excel to compare with last month’s experts, exposing a need for selection frequency visibility and fairness logs.

Identify bottlenecks and detours.

Record mental verification points.

Capture manual logic that the system does not automate.

Resulting hidden requirements: frequency visualization, historical filtering, and audit‑ready logs.

Dimension 2: Failure‑Mode Reverse Engineering (FMEA)

Ask users what goes wrong in their normal process, then probe how they handle those errors. This surfaces fault‑tolerance needs. Example: when an expert is absent at the last minute, the team must perform a supplemental selection, keep separate rooms, and add audit annotations.

Supplemental selection workflow.

Physical segregation of original and supplemental experts.

Explicit audit labeling for supplemental actions.

Dimension 3: Role‑Switching (Empathy Map)

Different stakeholders (managers, operators, auditors) have distinct concerns. Use an empathy map (what they say, do, think, feel) to ask each role specific questions, revealing role‑based hidden needs such as bulk import for operators or audit traceability for regulators.

Dimension 4: Rule‑Driven Design (Goal‑Directed Design)

Start from business goals—usually compliance—and work backwards to system functions. A regulation change requiring expert social‑security data to be considered for conflict‑of‑interest led to the hidden need for expert‑career‑history management.

4. Funnel‑Style Questioning

Combine open, exploratory, confirmatory, and leading questions to guide users from describing current practice to envisioning automated solutions. Techniques like intentional silence and reverse validation help elicit richer details.

“So my understanding is you need A + B + C, correct?”

5. Conclusion

Requirement gathering is a craft, not just a technique. By observing real workflows, probing failures, switching roles, and anchoring discussions in compliance goals, analysts can surface the full “iceberg” of needs and deliver solutions that satisfy users, auditors, and regulators alike.