When describing requirements or processes — are you referring to AS-IS (as is) or TO-BE (future state) processes? What tools do you use? What is the artifact of these analyses from a systems analyst?

When describing requirements and processes, it is important to clearly understand what exactly needs to be documented:

• AS-IS — current processes and system state, as they are now.
• TO-BE — the target state, how processes should work after changes.

Usually, the AS-IS is documented first to understand the initial situation, then the TO-BE — the desired model.

Various tools are used for this:

• BPMN diagrams for process description.
• Use Case diagrams and User Stories for requirements.
• Requirements tables and specifications.
• Modeling tools (e.g., Enterprise Architect, Draw.io).

Artifacts of a systems analyst are documents reflecting these models:

• Descriptions of AS-IS and TO-BE processes.
• System requirements (functional and non-functional).
• Diagrams and schematics.
• Technical specifications or requirements for developers.

These artifacts serve as the basis for communication between the business and the development team.