What it shows:
A mapping of specific actors (both human users and external systems) to the exact software functions they execute within the application boundary. While the Business Use-Case Diagram maps high-level strategic value streams, the Application diagram maps the literal software features required to achieve them. The Business diagram justifies the license; the Application diagram defines the clicks.
Why it’s needed:
Functional validation and User Acceptance Testing (UAT). This proves to the technical stakeholders that the software platform possesses the features necessary to do the job. During the final stages of the project, this diagram becomes the literal checklist for the UAT scripts—if a use-case is on this board, it should be proven that the user can successfully execute it before Go-Live.
When to use it:
Highly recommended for SADs and HLDs when deploying complex, feature-rich platforms where different personas require distinct subsets of application functionality. It is equally critical for Custom Dev to ensure software engineers build the correct features.
When NOT to use it:
Generally best to omit for “headless” backend infrastructure components (e.g., storage arrays, core switches) where there is no application interface for a user to interact with. It can also be skipped for simple “lift-and-shift” migrations where the application functionality remains the same as the legacy system.
Example:
