Coding agile practical combat series lesson 3: visual business analysis


Business analysis is at the upstream of the development process. Improving the quality of business analysis can reduce the repeated confirmation and scenario omission in the subsequent development, testing and integration process. The use of visual business analysis toolbox can greatly avoid the incompleteness and misunderstanding caused by the text version of business requirements description. Coding invited agile consultant, founder of business analysis toolboxWang HongliangThe teacher willVisual business analysisIn the course, we will lead you to master the basic tools and methods of visual business analysis to improve the quality and efficiency of business analysis.


Today I’d like to introduce you to visual business analysis. Business analysis refers to the text-based business description document SRSSoftware requirements specification。 During the offline training, I will let the students do a small interaction to intuitively feel the importance of detailed business analysis: first, let the students divide into groups, select a representative from each group to watch the graphics displayed on the screen, write down the contents they see and convey them orally to the team members, and the team members will reproduce them on A4 paper.


Because it involves a lot of precise element positions, it can’t be reproduced verbally. For example, the team member described: “this focus is called the center of the circle, and the side length of the square is half of the radius of the circle.” When the members reproduce the size, there will be a large deviation. It is conceivable that when we use oral or written form to express complex requirements, our development team and test team will have deviation in understanding, thus making mistakes in reproduction. If you ask the team members to take pictures of the figures and hand them over to the team to reproduce them, the possibility of duplication errors will be greatly reduced. In the same way, when we express business needs, the wider the information bandwidth and the more sufficient information we can express, the more accurate the information we convey, the more thorough the understanding of the team members, and the more accurate the product will be made.

For example, the form of withdrawing money from ATM is called IPO (input process output), which includes input parameters, processing procedures and output parameters. If the deduction of an account fails, it is necessary to return the deducted account balance to the account in advance. However, if it is only described under this condition and not marked under other conditions, it may be omitted and difficult to be identified. When we find that we need to supplement the relevant information, it will cause the format adjustment.

If we use the following format to write SRS, we need to spend a lot of time on documentation if we want to express it to the development team accurately. Because it is full of text, if there is an overlay during copying, the information will be lost. Therefore, using pure text to describe business requirements will cause problems: first, it is difficult to read; second, it will produce some errors which are not easy to find; finally, it will cause format adjustment when modifying, which will cause unnecessary new errors.


We can express the same business requirements in a different way——Swimlane flow chart。 The rectangle and diamond on the graph represent processing and conditions respectively. With the three swimlanes of user, ATM and account, each processor can clearly understand who is responsible; when there is a change, it can clearly show where the change has occurred. Using visualization to express business requirements can better present all information.


Language expression increases the possibility of misunderstanding, not to mention the tone can not be expressed in words, so when developers and testers have a misunderstanding, they will argue about who is right. When there is no way to judge, go upstream to ask ba. If Ba can’t judge, it will continue to ask up. In order to avoid wasting time, when Ba communicates requirements to development and test teams, it shouldCommunicate clearly to ensure the correctness and readability of requirements。 If Ba At the beginning, the requirement description is wrong, and if the customer confirms to the customer in the form of literal expression, the customer does not find the error, which will lead to the development and testing in vain. If the omission of scenario or condition is found during the test, the product quality will be reduced and the project will be delayed. If the omission can be found in the early stage, these hidden dangers can be eliminated as soon as possible The problem of repetition and postponement; it is also possible to encounter the situation that the final result is inconsistent and the development can not be carried out because multiple Ba processes the part in charge according to their own understanding, which can be avoided by mutual checking tools.

When business requirements analysts encounter requirements analysis and let developers play by themselves after sketching, it may be inconsistent with the original requirements. If problems are found and reworked, the development time will be over consumed. In order to avoid such a situation, it is necessary toThe requirements are refined to a certain extent, so that developers can make the correct version according to the clear requirements.

There is no needpriorityUsers will find various problems in the product, which can be solved by iteration. Each iteration is delivered once and sorted according to the priority of value. Users can give feedback in a shorter period, and the development can make more correct products. If the requirements always change, when the change occurs, the ba Mechanically passing changes from upstream to developers will result in Ba not being responsible, and developers are not responsible. There may be conflicts between the two, which will damage morale. In fact, requirement change is the vuca era. Whoever can better respond to the change will have stronger competitiveness, which is a very good thing for the whole team.

For example, I met a group of business experts to study what kind of fault is called. I asked how many factors are involved in judging whether the equipment is faulty? Experts say that there are four factors, so each factor has two options, listed in table form, a total of 16 combinations. This problem will be solved and the whole project can be pushed forward quickly. Software development team using the right tools, can play a very important role in improving, and even shorten the lead time, thereby improving the overall code quality. In the whole process of software development, the role of Ba is called business analystBuild a bridge between domain experts and technical expertsTo translate the domain requirements proposed by domain experts into a technical requirement, so that the technical experts can realize the correct process. Ba takes out a requirement document. Both sides have the same understanding. This is what an excellent Ba should do.

Take the scrum environment as an example. In scrum, the team is not refined, so Ba is also a part of the team. In the team, Po communicates with the end users, decomposes the collected initial business requirements into user stories, sorts the values, and sets product plans, product strategies, etc., then Ba should translate the initial requirements based on user stories into the requirements process that the development team can understand and implement correctly It is a bridge between the two. Demand is at the most upstream of the development process, then the quality improvement of demand analysis will have a leverage on the downstreamBa does not want to do low value things, but needs to better reflect the team value.


Requirement change is normal. If you can think of measures to deal with changes in advance, you can really master how to improve flexibility.The change is not only reflected in the code, but also needs to respond to the change at the demand level, in order to really promote the whole software engineering. When the requirements document is written out, the development team should see it, and the test team should see it. In scrum, scrum Master, Po, UI, end users and stakeholders all need to see it. However, everyone’s position is different, and they hope to see different information. If the documents are organized in an appropriate form so that each role can quickly understand and ensure high quality, the whole software development process can be greatly improved.

For example, a virtual bus rental project: domestic travel agencies want to rent foreign buses to arrange passengers’ itinerary. Upon receiving an order, they will arrange passengers to board the bus. At the end of the trip, the driver will settle the corresponding fees. By drawing the main business logic of bus leasing in the way of the following flow chart, it can be found that in some cases, the judgment benchmark is not specified. When encountering a business requirement, there may be various conditions to judge whether these steps can be pushed forward. When all these conditions are listed, the whole flow chart will become larger, and it will be difficult to read and maintain without layering, and it will be very difficult to change. If you want to realize that no matter how the conditions determine that the diagram does not change, you need to decouple The document produces a fixed and a changeable one.


You can see from the figure below that the form of the decision matrix is composed of conditions. The options of each condition are listed in the form of Excel. In this way, all four combinations are listed. All actions are car dispatching. Then the final conclusion is very clear. In this way, 100% conditional coverage can be ensured. If there is any omission, it is because the tools used cannot reach 100% coverage, such as pure text description. If it is a larger form, when it reaches hundreds or even thousands of lines, there may be human omissions. Therefore, it is necessary to use more scientific tools for self verification.

The table in the figure below is composed of conditions in the front, operation in the middle and expectation in the back. The form of give when then is the test case. The tester can use the table as a test case directly after getting the form. This decision matrix can not only provide 100% coverage, but also guide programmers to develop the correct code to achieve a good effect.



States are switched through specific operations. For example, state 4 cannot be switched to state 1. In this way, all corresponding states of the previous process can be sorted out, and the next analysis can be carried out. Take two examples: first, the approval of loans. Actually, there are three internal steps. The first step is to verify the real identity of users, the second step is to verify the credit status of users, and the third step is to verify the consistency of bank cards and user information. Internal processing data has sub status, but external display “loan approval”, so it is divided into internal status and external status. The other is called main state and sub state. For example, the steps of going abroad can be divided into air ticket hotel visa. Each sub process has its own state, and the three are parallel. The whole process is completed after all the states are completed.


As shown in the figure, whether the operation on the left can be performed in the current state can be checked. This is the so-called decision matrix. If an M × n matrix is listed, the matrix must cover all scenarios and list all state operations. In fact, when drawing the flow chart, only check mark is provided, and the information represented by blank space will not be expressed. Therefore, the decision matrix can be used to understand the abnormal information listed.


Good use of tools can better present the business requirements, so that developers understand more deeply. For example, the compendium shows that each unconfirmed point in the demand is a hole in the fishing net. Only when the net is propped up can we see how many holes are not filled. We can use mathematics or objective laws to find these potential points, and then confirm them one by one, so as to improve the quality and efficiency. If we follow these principles, we can develop new tools and better adapt to different business scenarios.

One picture is worth a thousand words. All the above cases are about how to show the corresponding business requirements in a visual way, such as diagrams, pictures, charts, tables, flow charts, etc. Business requirements analysis must be complete, and the following aspects should be ensured:

  1. Correctness: the requirements must be expressed correctly;
  2. Accuracy: it is necessary to be precise when expressing business requirements. If the expression is not clear enough, misunderstanding will occur. If mathematical expression is used, misunderstanding will be eliminated. Therefore, it is necessary to express requirements in an accurate way instead of using natural language too much;
  3. Consistency: try to keep the writing format, wording habits, expression methods consistent, using the same tool to express can make members understand more smoothly, let the team help more smoothly;
  4. Flexibility: requirements change is bound to happen, so the more flexible the document writing response, the stronger the ability to change. Also remember hierarchical expression, using different layers to separate the main process and condition judgment can make the document more flexible. When the requirements change, the scope of influence should be reduced as much as possible, so that the development team can transmit all the requirements change information faster, more accurately and better;
  5. Decoupling: including dependency injection. The primary business and dependency are based on the interface and verification. The interface is represented by prototype, and the verification is performed by Excel. The primary logic and secondary logic are separated. By decoupling, the ability of document response to change can be greatly improved, and the reusability of the team can be improved with higher efficiency and better quality;
  6. Multifaceted: there are many kinds of readers in need. We should consider the position of each kind of readers and the information they want to obtain. Therefore, the needs should be provided so that readers can easily obtain the information they want to know, improve their understanding and speed up their efficiency;
  7. Time saving: the time saved by Ba in work will become development time. In terms of document writing, reduce the work of format adjustment as much as possible, deliver as early as possible, repeatedly iterate, complete and deliver under the condition of ensuring quality, which can promote the development progress faster, and completion is more important than perfection;
  8. Invest time: spend time on meaningful things, such as improving the quality and readability of requirements expression, and reducing the investment of development and testing time, including reducing the problems of repeated communication and confirmation caused by omissions or errors;
  9. Prepare for a rainy day: there are a lot of contents that can be prepared in advance. If you can prepare the corresponding problems in advance, you can immediately check whether the analysis is comprehensive and whether there are any omissions. At the same time, the content reuse rate can also be improved;
  10. Finally, Murphy’s law. Remember that there must be problems where you don’t analyze them.

Click to watch the full video