OO System analyst Path--use Case Analysis Series (6)--use case implementation, use case scenario, and domain model

The last one said we had a preliminary business analysis and got the user, business use case and business scenario model. These three outcomes form the basic requirements framework and delineate the scope of the business. A baseline should be made at this time.

Of course, the first baseline contains very thick content, and there is more work to be done to achieve the full requirements. This article is about the detailed requirements process and outputs, as well as the contribution of these results to demand. Before you start, remind your readers to download the instance, and this article will only select a few of the examples to illustrate that the reader will be better able to understand the case.

The previous article identified business use cases, as well as business scenarios. This scenario only describes the business framework, followed by a scenario analysis of the business use cases. Use case scenario analysis uses three views, a business use case implementation view, a business use case scenario, a business entity model (domain model), and each business use case should also write a use case document, also known as the Use Case specification (UseCase specification). If there are non-functional requirements, such as performance requirements, throughput requirements, and so on, you should also write a supplemental use case specification. The use case specification will be described in the next article.

The first is the business use case implementation view. Not all business use cases must eventually be implemented in the system, so this view is meant to represent mapping relationships that range from requirements to system-wide. This view does not have the skill, also may omit, but the author recommends not to omit. The requirement should maintain the continuity and traceability of the process, which is the important guarantee of the software process controllable.

Business use case implementation view:

For each business use case implementation, it is necessary to simulate the implementation process of the use case. The previous article is a business scenario, and as the use-case implementation has already talked about "implementation," you should include the computer and simulate the business scenario from a human-machine interaction perspective. This is a conceptual model that expresses how a user's actual business is implemented in a computer environment, giving users a preliminary impression of how they will do business in the future. Note that while the computer is already involved in the requirements description, try to avoid the use of computer terminology, because the document is still part of the requirements document, is to communicate with the user, too many computer terminology will greatly reduce the user's understanding of the requirements. In writing a brief history of time, Hawking said that adding even a mathematical formula to a book would halve sales. Business use case scenarios are one of the conceptual models, but not all of the conceptual models. Conceptual model This article is not intended to be discussed, to put it simply, the conceptual model mainly includes business architecture and system prototype.

An activity diagram should be added to the business use case implementation to describe the use case scenario, and the following illustration is an example, drawn with an activity diagram. If you have more than one scene, you should draw multiple scene diagrams.

Business use case scenario (library process):