Business Analysis Methods and Modeling Techniques
The article outlines practical business analysis approaches—including flowcharts, sequence diagrams, prototype sketches, business and data model diagrams—and recommends modeling tools, emphasizing the importance of selecting appropriate visualizations to clarify complex requirements and improve communication between stakeholders and technical teams.
Recently, as the project progressed, more complex requirements have been added to the schedule, such as a technical consultant test‑drive scenario, an insurance consultant major‑accident/claim scenario, and split‑payment & coupon 3.0 integration.
Each of these items requires requirement research, business analysis, business modeling, and data modeling.
1. Business Analysis Methods
1. Flowchart
Cross‑role, multi‑lane flowcharts can be used to handle these situations, as shown below:
2. Sequence Diagram
Sequence diagrams express interactions of roles or business components in chronological order, for example the online maintenance reservation service (UST‑004):
1) User selects “Go to maintenance” and enters the reservation page;
2) After choosing a maintenance time, the backend checks stock availability and proceeds accordingly;
3) Based on the selected maintenance package type and quantity, the system calculates the estimated maintenance duration; the user may also specify a desired pickup time, which must be later than the estimated duration;
4) The user can view available daily time slots, see remarks (e.g., “offline positive review gives a hundred‑yuan red packet”), and confirm the reservation;
5) Vehicle registration methods: 1) upload driving license for OCR recognition; 2) manually input license plate;
6) Input mileage, contact person, phone number, whether door‑to‑door service is needed, and invoice information (if an invoice is required, collect type and header);
7) After submitting the reservation, a preview page is shown for user confirmation; clicking confirm sends the request to the Moby system.
3. Product Prototype Diagram
Usually produced by the product team, including prototype and UI diagrams, as shown below:
4. Business Model Diagram
Business modeling is a crucial part of a Business Analyst’s work; it is typically expressed as an object diagram. Good business models help understand requirements and facilitate communication between business experts and technical teams.
Comments: use precise terms such as “warehouse”, “warehouse ID”, “warehouse name”, and avoid vague labels like “inventory location”. The diagram should show the relationship between material inventory and warehouse master data, and exclude unrelated elements such as WMS.
Final revised version:
5. Data Model Diagram
Includes database conceptual models, physical models, etc., as illustrated below:
6. Others
Overall architecture diagrams, integration system diagrams, mind maps, etc., are also useful:
2. Modeling Tools
Common modeling tools include database modeling tools such as PowerDesigner, UML tools like Visio, Rational Rose, PlantUML, online diagramming tools like Processor, prototype tools such as Axure RP and Sketch, and general-purpose tools like Office software and Gantt chart tools such as OmniPlan.
3. Summary
1) Use appropriate charts (including graphics and tables) to solve different problems; specific chart types excel at specific tasks, so avoid blind copying and adapt flexibly. For example, sequence diagrams excel at showing interaction order over time, while object diagrams highlight relationships and causality.
2) Business Analysts primarily interact with people (often requiring domain knowledge), whereas Solution Architects focus more on machines; recognizing this distinction is key to performing well.
3) Whether dealing with business architecture or technical architecture, the core is “understanding requirements”.
More Recommendations
Message System Architecture Evolution
10 Best Practices for Microservice Architecture Design
Different Types of Architecture and Architects
High‑Availability Redis Service Architecture Analysis and Setup
9 Diagrams to Deeply Understand Docker Architecture
Disclaimer
This public account’s shared material is collected and organized from the internet; all text and images belong to the original authors and represent personal views only, unrelated to this public account. The article is for learning and exchange purposes; please verify the content yourself. If any infringement is found, contact the administrator for removal.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.