Software development: 20 rules of demand analysis (Favorites) JIANGTAO (Favorites)

zhaozj2021-02-16  43

Xing Xuehui / (IT Manager World)

For commercial users, they are hundreds of suppliers, and there are thousands of consumer customers. How to use the software management of intricate suppliers and consumer customers, how to do fine into a small piece of material, sales, adjustment, and stored goods, these are the reasons for commercial companies that require information management systems. The meaning of software development is here. It is the key to the success of the software development.

--- Manager: "We must establish a complete commercial management software system, including the import, sales, adjustment and deposit management of goods, is the chain business model of the headquarters - stores. Automatic ordering, supplier automatic settlement The store can be sold by sweep bar code, and managers can check with store products sales and inventory at any time. In addition, we have to provide reports on commodity operations for the government. "

- - Analyst: "I have understood the general structure framework of this project, which is very important, but we must collect some needs before formulating the plan."

- - Manager thinking strange: "I am not just telling you how my needs?"

- - Analyst: "In fact, you only explain the concept and goals of the entire project. These high-level business needs are not enough to provide development content and time. I need to discuss with the actual business personnel to use, then It can really understand the functions and user requirements to meet the business goals. After understanding, what is the existing components can be realized, which is developed, which saves a lot of time. "

- - Manager: "The business person is in investment. They are very busy, there is no time to discuss various details with you. Can you explain your existing system?"

--- Analysts try to explain the rationality of collecting demand from users: "If we are just guessed users' requirements, the results will not be satisfactory. We are just software developers, rather than procurement experts, operators or financial experts We don't really understand what you need to do in the internal operation of this company. I have tried it, I didn't really understand that these questions began to encode. The result is satisfactory to the product. "

--- Manager insisted: "OK, OK, we don't have so much time. Let me tell you our needs. In fact, I am very busy. Please start development immediately, and talk about your progress right at any time. I."

--- After the risk is hiding in the fog of demand

- - The above we see that a customer project manager and the analyst of the system development team discuss business needs. In project development, all project risk bearers are interested in the needs of the needs analysis. The risk assuments referred to herein include the customer's project leaders and users, development requirements analysts and project managers. This part of the work can be done, and it can develop a very good software product, and it will also satisfy customers. If the processing is not good, it will lead to misunderstandings, setbacks, obstacles, and threats of potential quality and business value. Therefore, visible - demand analysis has laid the basis for software engineering and project management.

- - Down the fog of demand analysis

--- Dialogue like this often appears in the process of software development. The demand for the customer project manager is in the case of analysts, like "watching flowers in the fog" and makes developers feel confused. So, we open the fog and analyze the specific content of the needs:

- · Business Demand - Reflects the organization or customer's high-level target requirements for the system, product, usually in the project definition and scope document.

--- · User Demand - Describes the task that the user must be completed using the product, which will be explained in an instance or scheme script.

--- · Functional Demand - Defines the software capabilities that developers must implement, allowing users to use the system to complete their tasks, thereby meeting business needs.

- · Non-functional demand - describes the operations of the system to demonstrate to user behavior and execution, etc., including products that must be complied with standards, specifications and constraints, and specific details and constructs of operation interfaces.

--- · Demand Analysis Report - The functional demand explained by the report fully describes the external behavior of the software system. "Demand Analysis Report" has played an important role in development, testing, quality assurance, project management, and related project functions. --- The customer project manager mentioned earlier usually clarifies the high-level concept and main business content of the product, and has established a guided framework for after success. Other any explanation should follow the "Business Demand" provisions, but "business needs" does not explain many of the details required for developers to provide development.

--- Next level demand - user needs, must be collected from users who use the product. Therefore, these users constitute another software customer, they know what tasks and some non-functional characteristics needs to be used. For example: the ease of use, robustness, and reliability, which will allow users to accept software products with this feature.

--- The manager layer sometimes tries to talk to the actual user, but usually they cannot accurately explain "user needs". User needs from the real user of the product, the actual user must participate in the process of collecting demand. If you don't do it, the product is likely to leave a lot of hidden dangers due to lack of sufficient information.

--- During the actual demand analysis, the above two customers may feel that there is no time to discuss with demand analysts, and sometimes the customer wants to say that the analyst does not have to discuss and write demand instructions to say users. Unless the demand encounters is extremely simple; otherwise it cannot be done. If your organization wants the software to succeed, you must spend a few days to eliminate the embarrassing place in the demand and some aspects that make developers feel confused.

--- Excellent software products are based on excellent demand, and excellent demand stems from valid exchanges and cooperation between customers and developers. Only the participants of both parties understand what they need, and the success of success is to establish a good cooperative relationship.

--- Because the project's pressure is increasing, all project risk bearers have a common goal, that is, everyone wants to develop an excellent software product that can achieve both commercial value and satisfying user requirements.

- - Review of customers

- - Customer and developer exchange require a good method. The following recommendations 20 rules, customers and developers can reach the following contents through review. If you encounter a difference, it will be reached by negotiation to achieve mutual understanding of your respective obligations, in order to reduce the future friction (such as one request and the other party is not willing or not satisfying the requirements).

--- 1, analysts should use the expression in accordance with customer language habits

--- Demand discussion focuses on business needs and tasks, so terms are used. Customers should teach analysts for analyzes related terms (eg, pricing, printing goods, etc.), and customers do not have to understand the terminology of the computer industry.

--- 2, analysts should understand the business and goals of customers

--- Only analysts better understand the customer's business, in order to make the product better meet the needs. This will help developers to design outstanding software that truly meets customers and achieves expectations. To help develop and analyzers, customers can consider inviting them to observe their workflow. If you are switching a new system, development and analysts should use the current legacy system, which is conducive to how the current system works, and its process is available. s

--- 3, analysts must write software demand reports

--- Analyst should be organized from all the information obtained from our customers to distinguish business needs and specifications, feature requirements, quality objectives, solutions, and other information. Through these analysis, customers can get a "demand analysis report", which reaches an agreement between developers and customers to develop product content. The report should be prepared in a way that customers think is easy to read and understand. Customers should review this report to ensure that the contents of the report have accurately express their needs. A high quality "demand analysis report" helps developers to develop genuine products.

--- 4, the explanation of the results of the demand work

--- Analyst may adopt a variety of charts as a supplementary description of the textual "demand analysis report", because the work chart can clearly describe certain aspects of system behavior, so various charts in the report have extremely high value Although they are not difficult to understand, customers may not be familiar with this, so customers can ask analysts to explain the role of each chart, the meaning of symbols and demand development work, and how to check the chart error and inconsistent Wait. --- 5. Developers must respect customers' opinions

--- If the user does not understand each other, the discussion about the demand will have an obstacle. Common cooperation can make everyone "listen to it". Customers who participated in the demand development process have the right to request developers to respect them and cherish their time for success. Similarly, customers should also demonstrate their efforts to develop people's common goals for the project.

--- 6. Developers should make recommendations and solutions for demand and product implementation

--- Usually, the "demand" said that the customer is already a practical implementation plan, and the analyst should try to understand the true business needs from these solutions, and should also find out that there is a system and current business. To ensure that the product will not be ineffective or inefficient; after thorough understanding things in the business sector, analysts can propose considerable improvements, experienced and creative analysts can also put forward some users without finding Very valuable system characteristics.

--- 7, describe product use characteristics

--- Customers can require analysts to pay attention to software easiness while achieving functional needs, because these ease-use characteristics or quality properties complete the task more accurate and efficiently. For example, customers sometimes require the product to "interface friendship" or "robust" or "high efficiency", but for developers, it is too subjective. The correct approach is that analysts understand which features have a negative impact on which characteristics is negatively influenced by inquiring and surveying the customer's "friendly, strong, efficient, and the specific characteristics included in the customer." Doing weighing to ensure reasonable payment.

--- 8, allowing reusing existing software components

--- Demand usually has a flexibility, and analysts may find that some software components are very consistent with customer description. In this case, analysts should provide some choices for modification requirements to reduce new. The development cost and saving time of the system, without having to be strictly described in accordance with the original needs. So, if you want to use some existing business common components in our products, they are not fully fitted with the features you need, and the flexibility of a certain extent is extremely important.

--- 9, requiring a true and reliable assessment for the cost of change

--- Sometimes, people will make different options when people face better and more expensive. At this point, it is necessary to evaluate the impact of demand changes to help business decision-making. Therefore, the customer has the right to develop a true and credible assessment by analyzing the development personnel, including impact, cost and loss. Developers cannot exaggerate assessment costs because they do not want to implement changes.

--- 10, a system that meets customer functions and quality requirements

--- Everyone wants the project to succeed, but this not only requires customers to clearly tell the developer's information about the system "what" what "do, but also asked developers to understand clear and restrictions through communication, must be clear Description Your hypothesis and potential expectations, otherwise developers developed very likely to make you satisfied.

--- 11, explain your business to analysts

--- Analyst to rely on customers to explain business concepts and terminology, customers can't expect analysts to become experts in this field, but only let them understand your questions and goals; don't expect analysts to grasp the fine potential of customer business Where they may not know "common sense" for customers.

--- 12, draw out the time clearly, and improve the demand

--- The customer is very busy, but in any case, it is necessary to take the time to participate in the "Mental Peak Conference" discussion, accept interviews or other activities for acquisition. Some analysts may first understand your point of view, and afterwards find you still need your explanation, please patiently treat some demand and demand refining process, because it is a natural phenomenon in people's communication, not to mention This is extremely important for the success of software products. --- 13, accurate and detailed description

- It is difficult to prepare a clear and accurate demand document. Since the problem of processing details is not only annoying and time consuming, it is easy to leave ambiguous demand. However, during the development process, this kind of fuzziness and inaccuracy must be solved, and the customer is precisely the best candidate to solve these problems. Otherwise, there is only to rely on the developer to correctly guess.

--- Temporarily add the "to-pending" flag in the demand analysis. This flag can indicate which is where it is necessary to further discuss, analyze or increase information, and sometimes it is also a "to be determined" because it is difficult to resolve or not handle it. Customers should try to explain the contents of each demand so that analysts can accurately write them into the Software Demand Report. If the customer does not accurately expresses, it is usually required to use prototype technology. Through prototype development, customers can repeatedly modify them with developers, and constantly improve the demand definition.

--- 14, timely decision

--- Analyst will require customers to make some choices and decisions, including processing methods from multiple users or in selecting compromise in quality characteristics conflicts and information accuracy. Customers who have the right to make decisions must actively treat this, do it as soon as possible, do decide, because developers usually only wait for customers to make decisions to act, and this wait will delay the progress of the project.

--- 15, respect for the feasibility and cost assessment of developers

--- All software features have their cost. Certain product features of customers may not be in technology, or implement it to pay high cost, and some demand tries to achieve performance that is impossible to achieve in the operating environment, or attempts to get some fundarated data. . Developers will have a negative evaluation of this, and customers should respect their opinions.

--- 16, priority for dividing demand

--- Most items do not have enough time or resources to achieve functionality. Decide which features are necessary, which is important, is the main part of demand development, which can only be responsible for setting up demand priority, because developers are impossible to decide the needs priority according to customer views; developers will be for you Determine the priority to provide information about the cost and risk of each requirement.

--- Under time and resource limitations, the need for the desired characteristics should be completed or completed. Although no one is willing to see that the needs of their hopes are not implemented in the project, after all, it is necessary to face reality, and business decisions sometimes have to narrow the project or extend the period of time according to the priority, or increase resource, or in quality. Find a compromise.

--- 17, review demand documentation and prototype

--- Customer Review Demand Documentation is a chance to give analysts bring feedback. If the customer thinks that the "Demand Analysis Report" written is not accurate enough, it is necessary to tell the analyst as soon as possible and advise the improvement.

--- A better way is to develop a prototype for the product. This customer can provide more valuable feedback to developers, making them better understand your needs; prototype is not an actual application product, but developers can translate them, expand their successful systems.

--- 18, demand changes To contact now

--- Constant demand changes will bring serious adverse effects to quality products completed within the scheduled plan. Change is inevitable, but in the development cycle, the more changes in the late stage, the greater the impact; change will not only lead to extremely high cost, but will be delayed, especially after the general structure has been completed, it needs to increase New feature. Therefore, once the customer finds that it is necessary to change the needs, please notify the analyst immediately.

- 19, the process of processing demand changes in accordance with the development team --- To reduce the negative impact of changes to the minimum, all participants must follow the project change control process. This requires not abandoning all proposed changes, analyzes each required change, considers, and finally make appropriate decisions to determine which changes should be introduced into the project.

--- 20, respecting the needs analysis process adopted by developers

--- The most challenging in software development is the collection of demand and determine its correctness, and the methods used by analysts have their rationality. Perhaps our customers think that the process of collecting demand is not cost-effective, but please believe that the time to spend demand is very valuable; if you understand and support the analyst to collect, write demand documents and ensure the quality of its quality, then The entire process will be more smooth.

--- "Demand Confirmation" means

--- Sign in the "Demand Analysis Report" confirmed that it is often considered to be a symbol behavior that the customer agrees with demand analysis. However, in practice, customers often see "signature" as a meaningless thing. "They want me to sign under the last line of the demand document, so I signed it, otherwise these developers do not start coding."

--- This attitude will bring trouble, such as customer wants to change the needs or say: "Yes, I am signed in the demand analysis report, but I don't have time to read all the content. I believe in you, you are not signing. "

--- The same problem also happens only the "signing confirmation" as an analyst of the task, once there is a need to change, he refers to the "Demand Analysis Report" says: "You have signed on the needs. So these are what we have developed. If you want anything else, you should tell us earlier. "

--- These two attitudes are not right. Because it is impossible to understand all the needs in the early days, there is no doubt that the demand will change, and the signature confirmation on the "Requirements Analysis Report" is the correct way to terminate the demand analysis process, so we must understand what it means .

--- Signature of the Demand Analysis Report is based on a baseline of a demand agreement, so we should understand this on the signature: "I agree that this demand document describes our understanding of the needs of the project, further changes The baseline definition is made through the change process of the project. I know that the change may enable us to reissue costs, resources, and project stages tasks. "The consensus to reach a certain consensus will make both parties to endure future friction, these Friction comes from the improvement of the project and the error or new requirements of the market and business.

--- Demand confirming that the true face of the fog is distinguished, showing demand, and draws the initial demand development work on both parties clearly, and helps form a continuous and good relationship of customers and developers, the success of the project. Layded a solid foundation

转载请注明原文地址:https://www.9cbs.com/read-27685.html

New Post(0)