OO system analyst path-case analysis series (3)-stakeholders of Business Modeling

After understanding the system goal, the system analyst should first not understand the business details, but discover people and things related to this goal. This kind of person and thing is called stakeholder in English. In Rose, the type of this kind of model is defined as business actor. Some documents are translated into stakeholders, so I prefer the translation method of stakeholders. This introduces the first step of Business Modeling: discovering and defining stakeholders.

Starting from this article, I will use a virtual instance to explain how to obtain the use case, and how to determine whether the use case acquisition is complete and whether the granularity is appropriate. In fact, when doing this, we are in the first stage of requirement analysis, namely the business modeling stage. With the help of this example, I will also elaborate on what business modeling should do and how it can be done to indicate that the business needs are complete, which can be called a complete Requirement Specification.

Generally, the business model can be established only when the following tasks are completed:

Discover and define stakeholders

Define business boundaries

Obtain Use Cases

Use Case Scenario

Draw a business entity model (Domain Model)

Prepare a vocabulary

The following is an example to illustrate how to complete these tasks. This is just a virtual case. Readers do not need to investigate its rationality and authenticity.

Now we have received a project called an online book lending system, which initially contacts customers. The business manager of the online book store told me this:

We were originally a traditional library, and the traditional method of borrowing books requires readers to come to the library in person. This is very inconvenient, and with the increase of the number of books and the increase of the number of readers, in particular, a large number of readers go to the library, which leads to insufficient space and insufficient staff. Therefore, with the help of the network, readers can borrow/return books through the network, which saves a lot of site maintenance and staff costs and allows computers to conveniently retrieve directories, this allows readers to borrow required books without leaving their homes. In order to send the book to the borrower, we have reached an agreement between ate express delivery and B city logistics company to send and withdraw the book between the borrower and the library. The reader presents and verifies the debit card on the internet, finds the books they need, and submits the application. After the librarians confirm, they will notify the logistics company to pick up the books. When the readers get the books, the logistics company needs to take the reader's ticket back to prove that the reader has obtained the book. Of course, in this process, the reader needs to pay. Returning books is also basically the same process.

Okay. Through this conversation, we have basically understood the system goal. Some anxious system analysts are preparing to start to ask about the borrowing process. The borrower's qualification is wrong, and some even draw a webpage in their minds based on years of development experience, consider how to implement this system.

What I want to say is, please never rush down. Because what we get is just a rough idea planned by non-computer professionals, and its feasibility has not yet been confirmed, we will begin to refine it on this basis, in the future, there will be a great risk of repetition or even failure.

After understanding the system goal, the system analyst should first not understand the business details, but discover people and things related to this goal. This kind of person and thing is called stakeholder in English. In Rose, the type of this kind of model is defined as business actor. Some documents are translated into stakeholders, so I prefer the translation method of stakeholders. This introduces the first step of Business Modeling: discovering and defining stakeholders.

What is stakeholder? Stakeholder is everything and things related to the business system to be built. First of all, we need to make it clear that the user is not the same as the user. Generally, the user is the user of the system. This is only part of the user. How can we understand all people and things related to the business system? I can share my experience with you through the following categories:

Owner

The owner is the investor of system construction. It is not necessarily the business party. For example, it can be assumed that the network construction of this library is invested by an international venture capital institution. It does not manage the library itself. It only owns the system of capital and obtains the return from the borrowing income.
It is essential and important to understand the expectations of the owner. The owner's money is the reason for the existence of this project. If the construction of the system does not meet the expectations of the owner and the investment is withdrawn, the good wishes will be blank.
Generally, the owner is concerned with the construction cost, construction cycle, and benefits after completion. Although these seem to have nothing to do with the system requirements, the construction cost and construction cycle will directly affect the technology you can use, the software architecture you can choose, and the system scope that you can afford. A project that cannot meet the owner's cost and cycle requirements is a failed project. Similarly, a project that meets the owner's cost and cycle requirements, A project that has not yet made any money is still a failed project.

Business Initiator

The business initiator is the maker of business rules. It generally refers to senior figures of the business party, such as CEOS and senior managers. They define business rules, define business scopes, and plan business objectives. Their expectations are very important. In fact, system construction is the embodiment of the Business and Management will of the business. Their expectations are generally vague and rough, but they cannot be violated or misunderstood. Otherwise, the system will be in danger of a complete failure. Business initiators are generally most concerned with the social impact, efficiency improvement, and cost saving of system construction. In other words, they only care about the meaning of statistics but not the specific details. However, if the built system cannot provide satisfactory statistical results, this must be a failed project. In the communication process of system construction, their will is usually rarely compromised, and system analysts do not have to worry too much about trying to persuade them to accept a solution that is contrary to their will. In fact, their expectations are very concise and rough, so they leave a lot of room for system builders to adjust and avoid risks.

Business Manager

Business managers refer to the personnel who actually manage and supervise business execution. Generally, they refer to middle-level cadres who put the will of the Business initiators into practice and supervise the work of bottom-layer employees. Their expectations are also important, and they are generally one of the main users of the system. They are concerned about how the system will implement their management functions, how to easily learn the results of business execution, how they issue commands, and how they get feedback. The expectations of business managers are relatively detailed and are the most important sources of information in the demand survey process. System Construction has the most relationship with business managers, which is also the most urgent task for system analysts. System analysts must clarify the ideas and ideas of business managers, and the results of business modeling must also be consistent with the business managers. In the process of system construction, the expectations of business managers can be compromised. An experienced system analyst can give them reasonable management methods and provide alternative management methods, to avoid unreasonable requirements that lead to high-tech risks or high-cost risks.

Business performer

Business executors refer to the bottom-layer operators who interact most directly with computers in the future. What they are most concerned about is what kind of convenience the system will bring to them and how it will change their working model. Their requirements are the most detailed, the availability and friendliness of the system, and the operational efficiency are most related to them. The style of the system interface, operation mode, data display mode, input mode, and business details need to be learned from them. They will be the touchstone of system success. Look and Feel, Form details and so on are the places where system analysts need to work harder to investigate with them. Such personnel have the highest expected flexibility and are most likely to persuade and compromise. At the same time, their expectations are often different, and all sorts of weird requirements are there. Their expectations must be subject to the expectations of business managers. Therefore, system analysts need to find common meanings from their expectations to solve most people's problems, when necessary, business managers can be relied on to influence and eliminate unreasonable expectations.

Third-party

A third party is associated with the business, but not the other person or affairs of the business party. For example, in this case, the borrower needs to pay the fee when borrowing books. If the payment is made through an online bank, the online bank becomes a stakeholder in the online borrowing system.
Third-party expectations do not have a decisive significance for the system, but will play a limiting role. In the system, such expectations will be embodied in standards, protocols, and interfaces.
Another typical third party is the project supervisor, and the system analyst must also clarify the expectations of the supervisor.

Publisher

The publisher is your boss. The boss's expectations are also very important. The boss is concerned about whether the project can make money, whether it can accumulate core competitiveness, whether it can establish a brand, and whether it can open up the market. The expectation of the boss will greatly affect the operation mode, technical selection, architecture establishment and scope of a project. For example, if the boss tries to open a market through this project and establish a brand at no cost, then the system analyst needs to explore as much potential business as possible to build a strong scalability, however, for business architectures with high costs, we should select newer but highly risky technologies. On the contrary, if the boss only wants to make more money through this project, the system analyst needs to guide the business party to compress the business scope, select mature technologies with low risks, and even ignore the business architecture, consider the maintainability of the system, but less consider the system expansion capability.
I am afraid it is not a successful project that the owner is satisfied with but the boss is not satisfied?

Related laws and regulations

Related laws and regulations are very important, but they are also the most easily overlooked. Laws and regulations refer to both national and local laws and regulations, as well as industry norms and standards. For example, to create a borrower's archive in this lending system, the borrower's privacy must be guaranteed. to trade with an online bank, the information security law must be observed. If the business party violates the requirements of laws and regulations, the system analyst should give them a point of failure to persuade them to leave a disclaimer in the contract. Otherwise, it would be depressing to accidentally get involved in a lawsuit.
In addition, sometimes some industry specifications must be observed. For example, online borrowing is used. The Network Requirement determines that the user must comply with the HTML specification to ensure that the user can browse the webpage normally.

User

A user is an abstract concept that refers to the expected system user. Users may include any of the aforementioned stakeholders. The significance of establishing a user-related model is that every user may be a role in the system in the future and participate in the system in real time, which requires programming. The other stakeholders mentioned above may only be useful in the demand phase and will not interact with the system. During the modeling process, both the establishment of the conceptual model and the establishment of the system model only start from the user and ignore other stakeholders. When creating a model in Rose, you only need to create a user model. Other stakeholders only need to be reflected in the document.

This article can only end here. Otherwise, readers should be impatient if it is too long. We have to subscribe it here. In the next section, I will export the expectations of the stakeholders step by step and obtain a rough outline of the demand scope.