01 Parking Service Business Analysis with a Focus on Actual Market Situations #

Whether it is the traditional development model or the currently popular agile development model, it all starts with the source - business requirements. If the requirement gathering and analysis phase is missing or not done well enough, the resulting errors will be magnified with each software iteration, leading to significant losses. While the cost in terms of money may be acceptable at times, the time cost and opportunity cost cannot be estimated.

Why choose “Shopping Mall Parking Business” as the requirement prototype? There are two considerations: firstly, the scenario is well-known and there is no significant obstacle in understanding the business; secondly, it can incorporate the microservices features we want to express, and the business complexity is relatively low, making it easier for development and impractical to practice.

Let’s delve into it step by step with the course.

Parking Fee Requirements #

I believe everyone often goes shopping in malls, whether or not you have parked your car, the parking lot in the mall is not a strange presence. This practical operation is carried out based on the business prototype of shopping mall parking fees. The business requirements are relatively simple (actual business is more complex than the features in the case), mainly to grasp the microservices technology stack we care about through simple business functions.

The main stakeholders are the property management department of the shopping mall, and the original requirements they put forward are as follows:

1. Users need to bind their mobile phone number to the mall’s system, add vehicles to it, and be able to check-in and receive points when they arrive near the mall every day. The points can be used to redeem limited mall coupons and car wash vouchers at designated locations in the parking lot.
2. Users can open a VIP parking monthly card through the system, which allows them to enter and exit the parking lot without additional charges. It is possible to recharge the monthly card for extension, and when recharging, a certain number of points are given to the users as a gift, which can be used as normal points. After recharging, users can receive a recharge notification.
3. If the user has not opened a monthly card, they must pay the parking fee in the system before they can exit. The amount of the fee is calculated according to the charging rules stipulated by the parking lot. After payment, the user will receive a payment notification.
4. Before entering the parking lot, users can see the real-time available parking space count.
5. In the system backend, the payment flow, recharge flow, parking space usage, and other information of users can be viewed.

The business scenario is clear and quite common (in actual scenarios, this system should be connected to other systems for data sharing, facilitating data analysis, statistical mining, etc., and the actual functionalities are more complex than this). Based on the above simple requirements, combined with the microservices technology stack, we will carry out a complete development practice from 0 to 1.

Requirement Organization Approach #

Scrum agile development practices have been applied in China for quite some time, and many companies have successfully applied it to product iteration development. This practical exercise will incorporate agile thinking to guide the development practice of microservices. In most cases, the requirement analysis work in this article is completed by the Product Owner (PO).

In the traditional waterfall development model, the process generally consists of requirement analysis, outputting requirement analysis documents, followed by high-level design, detailed design (database design), and outputting corresponding documents. Subsequent coding work is then carried out.

Agile development advocates working documents rather than detailed documents, so there is no need to strictly follow the traditional model and output a bunch of documents. Being able to clearly express and accurately convey it to team members is sufficient.

(Image source: http://agilemanifesto.org/)

Based on the original requirements, the PO outputs the user story list to form a requirement pool, known as the Product Backlog. In each iteration, items from the pool are placed into different iterations in priority order to form the Sprint Backlog. At the same time, stories are broken down into tasks (stories should have a coarser granularity than tasks and are a combination of functions) and the team members estimate and claim the tasks together. After summarizing the task workload, the total workload for the current iteration is formed. Based on the burn-down chart, as time goes by and work progresses, the completion status of tasks can be clearly seen from the chart. Kanban can be used by sticking the story tasks in different colored 3M sticky notes on a whiteboard to create a to-do list, work-in-progress list, and completed list. After a task is completed, team members adjust its position.

(Drawn with tools)

(Image source: Agile China)

To improve work efficiency, agile development tools are generally used to assist, such as Teambition, JIRA, and Zentao, which have good support for various agile phases. They are believed to help you save a lot of costs.

Requirement Analysis #

Based on the original parking requirements mentioned above, the integrated analysis can be grouped into six business modules:

1. Membership, including member information (mainly name, mobile number, and birthday), vehicle information (mainly license plate information), and monthly card information (recharge a certain amount of money, providing free entrance and exit within a specified period, targeting mall employees or office white-collar workers). It also includes check-in information.
2. Parking lot resources, including parking spaces (when a vehicle parks in a parking space, the system automatically marks it occupied, and the count of available parking spaces is updated in real-time at the entrance) and gate barriers (basic data, in real-world scenarios, it may involve scheduling of guard duty personnel and equipment maintenance, etc.).
3. Points, members receive points by signing in after arriving at the mall (e.g. signing in once allows for free parking for 2 hours, beyond which the billing rules apply). Points can be exchanged for mall discount coupons and car wash vouchers.
4. Billing, billing rules, vehicle entry (record the entry time of the vehicle, start billing), exit fee deduction (identify the license plate upon exit, pay the parking fee according to the billing rules, with two categories: temporary cars and monthly pass cars; temporary cars pay on site, monthly pass cars only exit after meeting the validity criteria)
5. Finance, payment transactions for vehicle entry and exit, monthly pass recharge fees, revenue statistics
6. Messages, payment messages for vehicle exiting, recharge messages for members
7. After redeeming the car wash voucher, car wash services are available in the parking lot.

User Stories and Task Organization #

Based on the above requirements, list several representative user stories, replacing the traditional requirement document. Convention: The mall parking system is referred to as the system for the following.

1. As an ordinary user, I want to be able to bind my phone number to the system, and enter my vehicle information so that I can pay the fees when I leave and receive notifications of the payment results.
2. As a system user, I want to be able to open a monthly parking pass for the parking lot and also receive additional points, so that I can exit without additional payment and pass through quickly.
3. As a system user, I want to be able to earn points through daily check-ins to exchange for mall discount coupons or parking lot car wash vouchers.
4. As a general user/system, I want to recognize the available number of parking spaces before entering the parking lot, so that I can make corresponding decisions.
5. As a monthly pass user, I want to receive consumption notifications and additional points when recharging my monthly pass.
6. As a system user, I need to pay the corresponding parking fee according to the billing rules when exiting, and receive payment notifications.
7. As a system admin user, I want to be able to see the usage of all parking spaces, user payment transactions, and recharge transactions for monthly passes.

Based on the above stories, break down the stories into more detailed tasks. Taking the first User Story as an example:

1.1 Bind phone number in the mall system and use a verification code sent to the phone to confirm ownership.

1.2 Complete personal information, including saving personal name, birthday, etc.

1.3 Enter vehicle license plate information, and calculate parking fees automatically when the vehicle’s license plate is recognized upon exit.

After listing the specific tasks for each story, the development team can evaluate the workload based on the tasks. The Fibonacci sequence (in hours) is commonly used for agile estimation: 0, 1, 2, 3, 5, 8, 13, 21, etc. It is recommended not to exceed 8. If it exceeds 8, it means that further breakdown is needed, ideally completing a task within one day. The estimation requires selecting a baseline complexity. For example, one DB interaction is considered as 1, and based on this, analyze the complexity of each story and use the previously mentioned method to estimate the working hours for a task.

Some friends may worry that if the estimated time is too short, they won’t be able to complete the task. However, this is just an initial estimation, and in actual execution, the actual execution is the basis. The burn-down charts of an agile team will not burn down perfectly like the ideal state.

In practice, many team members have a misconception: they focus on the time spent rather than the remaining working time, as shown in the burn-down chart.

Key Business Process Analysis #

Based on the requirements, identify the core business processes to guide the subsequent development of the core business.

Summary:

In this article, we combine Scrum agile thinking to analyze product requirements. The PO organizes user stories and core business processes, and the development team takes over the stories, breaks them down into specific tasks, and estimates the workload, which is then entered into the agile tool to prepare for the involvement of the development team.

Practice Questions for the Two Remaining Sections #

1. Intermediate developers generally do not pay much attention to requirements and focus more on improving their skills. However, if you want to progress quickly and far, you must insist on grasping both technical and business aspects. Try to list all the user stories and break them down into tasks and enter them into a specific agile development tool. Follow the full process of agile development and experience it firsthand along with the project.
2. Is it really unnecessary to retain documentation in agile?