Answer.

Background:

In classical and agile projects, the requirements for analytical artifacts differ: some require detailed specifications and class diagrams, while others suffice with simple tables/sketches. Many organizations have their own templates, but the real utility of documentation is determined by its relevance and applicability.

Problem:

The lack of a standard set of artifacts leads to confusion ("what to draw when?") while an excess leads to bureaucracy and outdated documentation that is unused by the team. Analysts often create artifacts "just for show" without consulting developers and testers.

Solution:

A competent systems analyst:

Conducts kickoff meetings with the team and the client, identifies their pain points, and the preferred formats for artifacts.
Forms a responsibility matrix (RACI) for the documentation: who needs which artifact, who maintains it, and at what stage.
Collaborates with the architect and team leads to agree on where it is necessary to use, for example, class diagrams (for complex logic), and where a BPMN process or mockup suffices.
Constantly refines and revises the set of artifacts throughout the project — relevance is prioritized over completeness.

Key Features:

There is no universal set of artifacts: different projects require different documents.
Communication and mutual agreement are the foundation of success (shared ownership).
Each artifact should solve a specific task, be alive and maintained.

Tricky Questions.

Can only one type of diagram (for example, BPMN) be used for all situations?

No, each type of diagram or document reveals a different aspect of the system: BPMN for processes, UML for objects and interactions, tables for reference data. Combining them is best practice.

Is a detailed requirements specification document always necessary?

Not always. In startups, pilots, and agile projects, lightweight documents based on the backlog may suffice — the key is that the team understands the tasks.

Can an analyst demand the team to follow their documentation template?

No. Documentation formats and templates should arise from discussions and agreements with the team and client, being convenient for everyone involved.

Common Mistakes and Anti-patterns

Mechanical copying of a complete set of documents from other projects.
Creating documentation "for the sake of documentation".
Ignoring team feedback, refusing to work with relevant artifacts.

Real-life Example

Negative Case: A systems analyst implemented 6 different diagrams for each process within a corporate project. The team drowned in documentation, no one read it, they worked based on verbal tasks.

Pros:

Desire to formalize the system at a high level.

Cons:

Time loss, confusion.
Inaccurate documentation by the time of implementation.

Positive Case: In another project, the analyst only recorded a BPMN diagram and a short attribute table, regularly clarifying and updating them based on meetings with developers.