Business and System Use Cases

Business and System Use Cases

Business Use cases have the same characteristics as system use cases. Therefore, the method of writing and reviewing use cases is applicable to both. What is described in business use cases is also described in system use cases. This forms a collaboration between system and user cases. But this brings two bad messages.

First bad news: writers and readers often mix the two, may put system behavior into business use cases, or attribute business operations to system use cases. It would be helpful to discuss how to do it, but the authors and readers usually do not realize the importance of doing so. Readers who use system use cases criticize that the business use cases are at a high level, but do not realize that providing detailed system behavior details is not what the business use cases should do. Business Case writers occasionally write system behavior details into the documents. As a result, the Business Director is not interested in such documents with detailed behaviors.

To reduce such confusion, the scope and layers of use cases should be often stated in the use case template, so that the use case writers can follow these rules and let readers understand these rules. If possible, try to use icons for use cases. Use a slightly different model and numbers (for example, a group starts from 1000 and a group starts from 1 ). At the same time, write some components that can be directly used and visualized. In this way, we can make full use of this cooperative relationship without obfuscation.

Second bad message: completely and correctly connecting to the system and user cases is not worthwhile. Generally, the business case writer should describe the business process to the system usage (usually not described. Before describing how customers use the new system in daily life, Case writers have spent time, money, energy, and enthusiasm. System case writers sometimes add one or two sentences in the business process to maintain consistency, but they are generally reluctant to rewrite a business case that contains new system functions.

In this way, a gap is formed between the system case and the business case, that is, the system case and the business case are inconsistent. Firepond's rusty Walters commented on this as follows.

I have some successful experience in developing complete business use cases as system use cases. Based on my experience, I usually divide business use cases into three layers: a few black box and cloud-level business use cases at the beginning, and then quickly convert them into white box and cloud-level business use cases; finally, it is expanded into white box and kite-level business use cases.

However, in this process, there is no clear connection between the business and system cases.

In the following discussion, rusty Walters of firepond elaborated on his experience in business process use cases.

◆ Rusty WALTERS: Business Modeling and System Requirements
I have benefited from reading your book earlier. I have tried to properly plan the problem and use new knowledge. Before reading: Before reading this book, I have written several functional requirements documents for applications in the product group. In an application development process, we compile system use cases at various levels, including summary, user, and sub-function levels. We mainly focus on system functions. I am very satisfied with the modeling results, and it is very easy to understand. At the same time, we feel that there is no need to develop business use cases to demonstrate the entire environment. The system summary use cases include all our needs. In the development of another application, although the same development group is responsible for use cases	Modeling, but the situation is completely different. In retrospect, I understand that the crux of the problem is that members of different groups approach the system from different perspectives. I used modeling from business process to technology, but some people used modeling from technology to business process. There is no doubt that the scope of each case is unclear among the two sets of designers. In a group from business process to technology modeling, they never write system use cases. In a group from technology to business process modeling, they never write business use cases. On the contrary, because both groups want to directly use the use cases prepared by the other party, it is inevitable that there will be positive conflicts and mutual accusations. At that time, the use case model became quite messy due to lack of foresight and necessary understanding in defining the scope of use cases. Until the end, the entire group was still not satisfied with the case model.
As a matter of fact, the entire group knows this is a problem, but it does not know the crux of the problem. Experience after reading: As I found in a group trying to understand and document the development process, modeling from core business to technology does not seem to cause any confusion. 160 When we discuss business processes and their internal working methods (excluding software and hardware systems), everyone knows. The chaotic areas are indeed related to the business and department scope. Starting from the brief-level (cloud-level) Black Box cases in the business, we are all very clear about these cases, even those who are engaged in underlying modeling. Then, as described in the book, a very brief white box case (cloud-level) will soon be written.	When we decided to discuss the next low-level use case, the confusion caused by the design domain (that is, whether we are discussing the entire business or a certain department) emerged. This issue also relates to how to create subsequent use cases. In a special example, the preceding two steps are deleted when we realize that the implementation in the call case should not be part of the current case. At the same time, the development team does not plan to expand business use cases as system use cases. Although it is difficult to pay attention to and correct the entire process during the meeting, it is easier to understand the problem domain after the meeting. In the process of docized meeting results, I used the design domain context map and the icons to show the scope and layers of each use case. If the figure is simple enough, it will impress readers and appear directly in their minds.

 

 

This article is excerpted from the book "writing effective cases"

[Us] By alistaircockburn

Translated by Wang Lei and Zhang Li

Book details: http://blog.csdn.net/broadview2006/article/details/7736848