Business AnalysisBusiness Analyst

What artifacts and documentation are mandatory for a project, and how to ensure their relevance during changes?

Pass interviews with Hintsage AI assistant

Answer.

Business analyst artifacts are documents and diagrams that capture requirements, processes, and specifications. They are necessary to ensure transparency, track changes, and prevent misunderstandings among project participants.

Key artifacts:

  • Business Requirements Document (BRD) — captures the goals and objectives of the project.
  • Specification (SRS) — technical description of system requirements.
  • Business process diagrams (e.g., BPMN, UML Activity Diagram).
  • Requirements Traceability Matrix.
  • Prototypes, mockups, sketches of interfaces.

To ensure relevance:

  • Implement processes for regular review and updating of documentation
  • Use collaboration tools (Confluence, Jira, Miro, etc.)
  • Designate responsible persons for keeping artifacts up to date

Key features:

  • existence of a single source of up-to-date information (Single Source of Truth)
  • formalization of requirements and processes
  • transparency and ease of knowledge transfer within the team

Trick questions.

Can one rely solely on a single high-level specification without additional documentation?

No, details and diagrams are necessary for different groups: development, testing, and user training. A lack of information may lead to mistakes during implementation.

Is it acceptable to store documentation on the analyst's local computer without synchronization with the team?

No, documentation must be stored centrally and be accessible to the entire team.

When should documentation be updated — only at the end of the project or during changes?

Documents should be updated as changes are made; otherwise, the risk of informational desynchronization arises.

Common mistakes and anti-patterns

  • Storing documentation only with the analyst or in an isolated location
  • Lack of regular updating processes
  • Neglecting diagrams and visualization of business processes

Example from real life

Negative case: Documentation is only updated at the end of the release. During implementation, contradictions arise between development tasks, testing, and customer expectations. Pros: saves time at the start. Cons: disorganization, bugs, rework.

Positive case: Everything is stored in Confluence, responsible individuals regularly update artifacts, and there is a review of changes. Pros: transparency, quick adaptation to changes. Cons: requires clear discipline and process.