Examples of requirements analysis capabilities: the introduction of the domain model

Once encountered a system requirements, the requirements analyst to hear the customer said to increase the "Modify employee password" function, this function is written in the document intact. If you give this requirement to the implementation staff, a lot of the implementation staff will add an attribute "password" to the "Employee" class. If only use the noun method, to verify the demand, fully conforms to: "Employee", is a more important concept. "What what, can be extracted as a property", so "employee's password" can be distilled into the password attribute of the "Employee" class.

Realize the person hissed: "Everything OK." "

Is it really OK.

Requirements Scenario: separation of employees and users .

If you put the password in the employee, based on the crud approach, we usually put the employee changes to an interface. That is, the administrator adds a person, the system defaults to set the corresponding person's password.

At this time, the IT department raised objections, the increase of staff, is the Human resources department, and whether to open the account to employees, is the information center, not all employees are open account, the HR department has no right to open the account without permission.

Account "Yes," said the IT department, "user account."

Well, we lost an important concept--the user.

The same truth, employees to leave the time, but also to the information center to sell households, and then to the HR Department for separation, so we put password into the staff, is not appropriate. Employees need to be separated from the user.

Requirements Scenario: Consolidation of employees and customers, suppliers, partners:

Customers put forward new requirements: The original we have established are employees and passwords, now, we have to get through the enterprise supply chain, to our suppliers and customers including partners, conditional open system functions. Therefore, they also need to have an account and login password.

Whether to set up the proxy separately or to merge them into an abstract class. Without considering the performance of the system, we can temporarily apply the approach of "analysis mode" to abstract the person (or party) domain object.

Requirements Scenario: Separate account login

The customer said: "I want the employee to only select the role he wants to use after logging in." "What does that mean.

For example, Zhang X, in the group is a cashier, and in the group of a subordinate company, is an accountant, he was working in the group in the morning, afternoon, in the subordinate company to work. Therefore, when you log in, you need to select a role. "

The customer is not too easy to distinguish between employees and users, in the description, it will confuse the use of employees and users of the two concepts. In addition, posts and roles are very similar to two concepts.

In the absence of a unified stand-alone login server, you feel that there is a problem with this approach (think about it). , and persuaded the client: "Can you build two accounts for you?" ", the user also did not think carefully, incredibly agreed." Therefore, at this time a person, it corresponds to two accounts, the password. Nature cannot be put into the person.

Let's imagine the login process at this point, and the simple interactive steps are as follows.

Actor login using account and password,

The system verifies that the account and password are valid and shows the allowed function operation.

Requirements scenario: Selective activation

If the customer insists that only one person can log in with only one user account, what will it look like.

With user accounts and password logins, the system needs to list all of its roles, and the roles are listed by company,

Actor activates a certain role under a company. (for dynamic activation of roles, you can refer to the RBAC model, which is no longer spoken here.) ）

The problem to consider arises (the extended flow in the use case):

Actor has logged into the system elsewhere (activating other roles).

Our existing domain model is that the role is related to the company (legal entity) and what to do if the customer raises the role and department-related.

Requirements Scenario: Bounding context

JHF, my main head of BSP, has had a lot of discussion about people and users, as well as positions and roles. The conclusion is that this is to look at the same thing from different angles, in the enterprise resource model, HR is an important enterprise resource, and in the privilege model, manpower is the limited unit. Therefore, they should be divided into two different bounding contexts, and the bounding context is an important part of the domain model.

Digression:

As a participant in the LOUSHANGBSP product, I have been bothered for these needs (more than I lift out) for a long time, fortunately, now, the BSP in the organization and permissions model is relatively rich enough to deal with these needs scenarios, now, I can put some simple requirements, share to everyone.