Data and Process Analysis
In short: The systematic examination of data flows and workflows, to understand, document or improve them.
In more detail: Before implementing new software or a new workflow, an analysis is done of which data arises where, how it’s processed, and which process steps are needed — often visualised with tools like UML diagrams. The basis of any well-founded requirements analysis in application development.
In Depth
In data analysis, the focus is on WHICH data exists: which entities there are (e.g. customer, order, product), how they relate to each other, and what attributes they have — the result is often a data model or entity-relationship diagram. In process analysis, the focus is on HOW workflows function: who does what, when, in what order, with which decision points — represented, for example, as an activity diagram (one of the UML diagram types) or a BPMN flowchart.
Both analyses usually belong together, because processes create and change data: an order process (process view) creates and updates records like order, payment, delivery status (data view). A clean analysis BEFORE implementation prevents expensive design mistakes — a data model only recognised as inadequate halfway through development is considerably more expensive to change afterwards than at the drawing-board stage.
In practice, this is often combined with interviews with subject-matter staff, existing documentation, and observation of the current process, before a target concept for the new software is developed from that.
Typical modelling tools
Besides UML diagrams, other notations are used depending on focus: entity-relationship diagrams (ERD) for pure data structures and their relationships to each other, BPMN (Business Process Model and Notation) for company-wide business processes with several involved roles, and simple flowcharts for simpler, linear workflows. The choice of tool depends heavily on who will later read the result — a UML class diagram is primarily meant for developers, while a BPMN diagram is often also meant to be understood by subject-matter staff with no programming knowledge.
See also: UML, Application Development, System Integration