Answer

In the history of system analytics, one of the most difficult tasks is to identify and formalize non-obvious, vague, or hidden requirements. Often, the client cannot clearly explain what is needed or uses terms without revealing their true expectations.

Key Features:

• Implicit requirements are identified through analytics, active listening, clarifying questions, interviews, and observation.
• Formalization occurs in a language understood by both the client and the developers (e.g., using user stories, BPMN scenarios).
• It is essential to document and agree on clarified formulations with the client to avoid ambiguities.

Background

The issue of unformalized requirements has been known since the time of the first implementation projects. Initially, simple interviews were used for this, and now user story mapping, prototyping, and facilitation are also applied.

Problem

Implicit requirements lead to incorrect task formulation, wasted efforts, and conflicts between parties.

Solution

Utilize interview techniques, visualization (process maps, prototypes), facilitation, and clear documentation of results. Check for feedback after each stage of requirement fixation.

Trick Questions.

Can all requirements be formalized in advance before the project starts?

No, many requirements are clarified and identified during the work process as prototyping and project refinement occur.

Should only explicitly stated client wishes be recorded?

No, the analyst should also work with implicit expectations, analyze business goals, and identify hidden needs.

Is the task of the system analyst solely to translate requirements into technical specifications?

No, the analyst is also responsible for formalization, agreement, and clarification of requirements, as well as identifying conflicts.

Common Mistakes and Anti-Patterns

• Not documenting interim agreements.
• Assuming all requirements are equally important.
• Documenting only what is explicitly stated, without analyzing actual processes.

Real-Life Example

Negative Case:
The analyst recorded everything the client said in the project without clarifying details. Pros: development started quickly, saving time on analysis.
Cons: many rework and conflicts with the client due to incorrect expectations.

Positive Case:
The analyst created prototypes, conducted clarifying sessions, and documented implicit requirements together with the client.
Pros: high accuracy of requirements, satisfied client, fewer conflicts.
Cons: costs for facilitation and feedback gathering.