From Business Modeling to System Use Case Diagrams: A Complete Guide to Requirements Analysis

This article provides a comprehensive guide on how to distinguish and create business use case diagrams and system use case diagrams during software design. The content is structured into three main parts.

Part 1: From Business Modeling to Business Use Case Diagram

The first step in any project is to clarify the vision - understanding why the work is being done, who benefits, and the value it brings. The article emphasizes that without a clear, shared vision, developers may run in the wrong direction, wasting effort. When defining vision, one must identify the target organization and its "leader" (the person whose interests the system prioritizes), as well as refine improvement goals that focus on organizational behavior metrics rather than system functions.

Business use case diagrams represent the value an organization provides from an external perspective. Key components include: business actors (organizations outside the business boundary that interact with the studied organization) and business use cases (the value that actors hope to obtain through interaction with the organization). Business workers and business entities do not appear in business use case diagrams because they represent cost, not value.

Business sequence diagrams depict the current state of business processes. The article warns against several anti-patterns: detailing to storage carriers like database tables, expanding to entire organizations without distinguishing internal personnel or systems, focusing on non-core domain tools, treating timers as actors, assigning超出能力范围的责任 to business objects, and including overly detailed internal system interactions.

Part 2: From Requirements Design to System Use Case Diagram

After clarifying the current state of domain business and understanding how to improve it, the next step is system design. The article discusses requirement elicitation methods including research, questionnaires, interviews, observation, and competitive analysis. It outlines four strategic approaches: pioneer (market leader), pursuer (studying leader's strengths), flank attack (focusing on niche markets), and guerrilla warfare (relying on regional advantages).

System use case diagrams are more detailed than business use case diagrams, showing what individual external entities receive from业务流程中的价值. A system is defined as something that encapsulates its own data and behavior, capable of independently providing services externally. System actors can be people or other systems outside the studied system that have functional interactions with it. Actors are categorized as primary actors (who actively initiate use cases) and supporting actors (who passively participate in interactions).

The article provides detailed requirements for use cases: they must be mappable from external messages pointing to the system in business sequence diagrams, must provide value to actors, must have clear target customers, and should not be described as CRUD operations on database tables.

Part 3: Use Case Specification

Use case specifications further refine requirements with: preconditions and postconditions (constraints that must be satisfied before and after the use case), stakeholder interests, basic paths (the most successful and core value path, typically following a four-step pattern: request, validation, change, response), extension paths (for handling exceptions and unexpected situations), and supplementary constraints (field lists, business rules, quality requirements, design constraints).

The article concludes that code only creates value when applied to business. The equation "enterprise profit = requirements - design" highlights the importance of requirements. Understanding the domain, truly investing in understanding the business, and doing valuable work represents significant progress toward better design.