Interpreting the five key factors of agile Demand Analysis

Most people in mathematics and computer languages have always thought that programming and architecture are the greatest part of the entire software life cycle, however, after actual work, we will find that in commercial products, demand analysis is the key to the success of a commercial software.

Many of the problems that have emerged in today's software engineering field, such as defects and improper use of resources, are due to unclear requirements. Some software people may even say: "demand changes are the source of all evil" and have received a lot of responses at the moment. So far, what are the main problems in the business it demand analysis process? What is agile requirement analysis? What are the differences between product-level and project-level requirements? What are the five key points in Agile demand analysis methodology? On the above hot topics, Wu Qiong, general manager of Jacob's China Region, shared his views.

 

Three major symptoms

In WU Qiong's view, two demands, contract-based verification, and lack of product requirements have become the three key points of current demand communication.

Two requirements: user (business) requirements and software requirements. Most of the user requirements are completed by business personnel who are not familiar with it. They are attributed to the stream of consciousness, which basically reminds me of what to write. The software requirements are compiled by the IT staff, filtered, sorted, added, and deleted by technical thinking, and include technical words such as algorithms, database design, and architecture, business personnel often do not know the cloud in the document.

Contract verification-the business and technical personnel attempt to contract the demand and determine it after communication, without fully considering the possible changes in demand during the software development process.

Lack of product requirements-projects are fragments and products are total. The relationship between the two lies in that projects are a process of constantly improving products. Due to the popularity of PMP (projectmanagement professional) and project management in China, more IT requirements exist in the form of projects, and the accumulation of product requirements is often ignored, most of the final results are projects (requirements) but lack of product requirements.

The specific differences between project-level and product-level requirements. If the difference is not obvious for a few or more years ago, for a brand-new product, Project (demand) = product (demand ). With the passage of time, the distinction between the two is gradually clear, because there are fewer and fewer new projects, more needs are in the maintenance and upgrade of old products. Taking coffee as an example, upgrading from basic to version 1.1 may be a button. When communicating with the customer, you need to instruct the customer to find out whether the project-level or product-level requirements are required, whether the whole coffee maker needs to be made or simply needs to add new buttons. If you want to create version 1.2 again in the future and add more buttons, what should you do at this time? The requirements of the new button, and some changes with the previous button. If the differences between the two requirements cannot be clarified, as the project requirements accumulate, all (requirements) are segmented at the end, which is incremental and lacks a general panorama.

As a matter of fact, business it needs have resulted in today's chaos. The rigid understanding of cmme (Capability Maturity Model Integration, Capability Maturity Model Integration) and Chinese enterprises can be said to be "indispensable ". In terms of understanding the "two requirements", cmme has specific sub-items, user requirements and software requirements. However, it is worth mentioning that, in fact, it does not explicitly require two documents or two sections to be written, but only to express the two stages of demand refinement. Unfortunately, many domestic cmme certification enterprises do not really intend to understand its connotation, but just show rigid performance.

This has also happened to some projects recently. You have made a user requirement first, and then spent a lot of time writing software requirements to meet the authentication requirements, but in the end, no one looked at the software requirements, and everyone was just dealing with it. cmme became a decoration.

 

Requirements run through the entire process of software development and testing

In WU Qiong's view, the greatest contribution of agility lies in its recognition of the entire software project. When it comes to agile demand analysis, it actually involves a core issue: Do you want to acknowledge that (software) needs can be clarified and determined from the very beginning? The answer to agility is no! In traditional waterfall development, contract-based verification is more often used. Most customers' Ideological Bases are initially determined based on requirements. But in fact, this is basically an "impossible task" in the current stage and does not conform to the nature of software development. In agile requirement analysis, the requirement should be continuously changed, iterated, and improved throughout the entire software lifecycle.

The agile requirement analysis believes that the requirement should be based on the case-centered requirement document system and adopt collaborative rather than contract-based communication methods. There are five key points:

• Use Cases;
• Collaboration;
• Iteration, that is, the requirement is not finalized, but the main framework is completed first, and then gradually refined through iteration;
• The analysis is supported throughout the process, and requirements are also analyzed. The output results of the analysis model should be separated from requirements;
• Break down use cases into user stories to drive development and testing throughout the software life cycle.

 

Business/technical communication frequently shows "two demands"

At the same time, we need to consider changing the two requirements into one document without having to distinguish between user and software requirements. SA (System Analyst) will take the lead in the first requirement draft to coordinate and communicate with all parties. Ideally, the entire team should be established before the project starts, including the writing and iteration involved by customers and developers, it is not a milestone for users by technicians. Generally, a SA in a project corresponds to 5 ~ 9 developers are more appropriate.

 

Balance between requirement docalization and agility

Use Cases and user stories. According to the agile master Martin's blog, the two are both ways of organizing requirements, but their purposes are different. The purpose of the use case is to clearly describe the requirements, the purpose of a user story is to break down requirements into units that can be used for iterative planning. Corresponding to product-level and project-level documents, use cases are product-level, such as coffee maker. No matter how many different versions are available, some core functions remain unchanged. These are all product-level requirements. User stories are project-level, which is a "discard" type ".

Further, a user story is actually one or more complete business scenarios, while a use case is an abstraction of a scenario. A use case can contain hundreds of thousands of scenarios. User stories are based on the development philosophy. They not only need to consider the business, but also how to implement multiple factors, including workload, task allocation, project risks, and architecture risks. Some people think that writing user stories is extremely simple, but in Wu Qiong's view, many people are still using functions to use user stories, which is not uncommon, without understanding the essence of user stories.

Taking ATM withdrawal as an example, the normal process is to insert a card, withdraw money, and take the money away. This seemingly simple scenario requires a lot of work and can be simplified as necessary. Some people think that a user story is a scenario, So let's turn it into a scenario step, so it becomes a functional point. In fact, they ignored a point. The user story is still a scenario that simplifies but guarantees the complete business value. What factors are involved in building user stories for ATM withdrawals? Do I need to enter a password for withdrawal? Can I cancel the password entry process when I make a small withdrawal? After obtaining the money, print the bill and check the balance. Which of the following functions are highly risky and need to communicate with the core of the bank? This not only involves (function) priority issues, but also simplifies user stories based on principles. For example, you can consider creating a user story. The deposit card does not need to be verified, and the quota is one thousand. When you get hundreds of dollars, the Bank verification process will be canceled. In this case, we often need to take into account risks into account situations, which require multi-party communication. Similar user stories are simplified in many cases, but they must be simplified in black box mode. In the process of simplification, it is also a white box process to find (User) stories and consider how to adjust the workload reasonably to improve efficiency.

In terms of implementation, in addition to projects such as the Internet and online games that emphasize fast delivery or have a short life cycle and a highly variable business model, the pure use case model can be used) it is unrealistic for enterprise IT projects to fully accept the requirement without being documented. A more practical solution is to find a balance between document-based and agile requirement analysis, add a requirement case with a user story, and then drive development in this way. Currently, this is a practical mode that is more suitable for agile needs of large enterprises.