OO System analyst Path--use Case Analysis Series (3)--stakeholder of business modeling

Starting from this article, the author will use a virtual example to illustrate the method of acquiring use cases, and how to determine whether the use case acquisition is complete, the granularity of choice is appropriate. In fact, in doing these things, we are doing the first phase of requirement analysis, the business modeling phase. With this example, I will also explain what business modeling should be done, and to what extent it can be said that the business requirements have been complete and may be called a complete specification of requirements.

In general, the business model is established only when the following tasks are complete:

Discovery and definition of stakeholders

Draw a business boundary

Get Use Cases

Draw a use case scenario diagram

Draw business entity model (domain model)

Compiling vocabulary lists

The following is a case to explain how to complete the work, this is only a virtual case, its rationality and authenticity of the readers do not have to investigate.

Now we received a project, is an online book lending system, initial contact with customers, online library business owner told me this:

We were originally a traditional library, the traditional way of borrowing requires readers to come to the library in person, which is very inconvenient, and with the increase of books and readership, especially, and a large number of readers to the library, so that the library is not enough space, staff. So think of the use of the network, so that readers through the network to borrow/return, so you can save a lot of site maintenance and staff costs, while the computer can easily retrieve the directory, so that the reader can borrow the book to need. In order to send the book to the borrower, we have contacted a speedpost company and B City Logistics company, and initially reached an agreement to send and retrieve the books between the borrower and the library. Readers on the internet to show and verify the library card, find the books they need, submit applications, the librarian confirmed, will inform the logistics company to fetch books, when readers get the book, logistics companies need to take the reader's signature back to prove that the reader has got the book. Of course, the reader is required to pay for the process. Returning a book is basically the same process.

Well, through this conversation, we've basically learned about the system goals. Some anxious system analysts are already ready to start asking questions about the process of borrowing books, and even some people have drawn up a Web page in mind with years of development experience to consider how to implement the system.

The author wants to say is, please do not be anxious to go down. Because what we get is a very sketchy idea that is planned by a non-computer professional, the feasibility of which has not yet been confirmed, and it starts to refine on this basis, and the risk of repetition or failure in the future is great.

After understanding the system goals, the first thing a system analyst needs to do is not to understand the details of the business, but to find people and things that are relevant to the goal. This kind of person and thing is called stakeholder in English, and in rose the type of such model is defined as business Actor. Some of the data translated into the stakeholders, the author is more interested in this translation method. This refers to the first step in business modeling: discovering and defining stakeholders.

What is a stakeholder? The stakeholders are all people and things related to the business system to be built. The first thing to be clear is that the stakeholder is not equal to the user, and the usual meaning of user refers to the users of the system, which is only part of the stakeholder. How do you understand all the people and things related to the business system? The author can share the experience is through the following categories to find:

Owners

The owner is the sponsor of the system construction, the investor, it is not necessarily the business side. Suppose, for example, that the network construction of the library is invested by an international venture capital institution, which does not manage the library itself, but that it only owns the system from the capital and pays for the income from the library.

Understanding the owner's expectations is essential and important, and the owner's money is the reason for the existence of this project. If the system construction does not meet the expectations of the owners, withdrawn investment, then the good desire is also empty.

Generally speaking, the owner is concerned about the cost of construction, the construction cycle and the benefits after completion. While these seem to have little to do with system requirements, the construction cost and construction cycle will directly affect the technology you can use, the software architecture you can choose, and the range of systems you can afford. A project that fails to meet the cost and cycle requirements of the owner is a failed project, and similarly, a project that reaches the owner's cost and cycle requirements but does not earn money is still a failed project.

Business-Presenting person

The business proposal is the business rules of the formulation, generally refers to the business side of high-level figures, such as the CEO, senior managers and so on. They develop business rules, delineate business scope, and plan business objectives. Their expectations are very important, in fact, system building is the business of the operator and management will reflect the. Their expectations are generally more principled and sketchy, but they cannot be violated or misunderstood, or the system will be in danger of total failure. Business advocates are generally most concerned about the social impact, efficiency improvements and cost savings that can be brought about by system construction. In other words, they only care about the statistical significance and not the details, but if the construction completed system does not give them satisfactory statistical results, this must be a failure of the project. In the process of system-building communication, their will is generally rarely compromised, and system analysts do not have to bother to try to persuade them to accept a plan that is contrary to their will. In fact, because their expectations are very principled and rough, so left the system builders a lot of room for adjustment and risk avoidance.