Chapter 2 Customers' needs View
Advanced Management of the Contoso Pharmaceutical Company, Gerhard, meeting with the information system development team of C O N T O S O, new administrator C Y N T H i A. "We need to establish a chemical tracking information system", G E R h A r D said. "The system can record chemicals in the warehouse or a laboratory, so that chemical experts can directly get the drug needed from someone downstairs, without having to buy a bottle of new. In addition, health The health department also has to write some reports on chemical drugs for the federal government. Can your team have developed the system within five months? "
"I have understood the importance of this project, G E R H A R D" C Y N T H i A said, "But before I developed the plan, we must collect some system needs."
G e r h a r d is very strange "What is your meaning? I am not just telling you how my needs?"
"In fact, you only explain the concept and goal of the entire project," C Ynthia explains, "these high-level business needs cannot provide us with enough details to determine what software to develop, and need more For a long time. I need some analysts to discuss with some chemical experts who know the system use, and then they can truly understand the various functions and users required to achieve business goals. We don't even need to develop a new software system. This saves a lot of money. "
G e R h A r D has never encountered a similar view with this system developer. "Those chemical experts are very busy" he persists, "they don't have time to discuss various details in detail, can you let people under your hand illustrate the system you want?"
C Y N T H i A Try to explain the rationality of collecting demand from users using new systems. "If we just guess the requirements of the user, we will not be satisfactory. We are just software developers, but non-chemical experts. We don't really understand what chemical experts need this chemical tracking system. I have tried. I didn't really understand that these issues were rushing to start coding. There were no people to be satisfied with the product. "
"Okay, ok, we don't have that more time" G E R h A r d insisted. "I will tell you the demand, please start the development system immediately. Tell me your progress at any time."
Dialogue like this often appears during software development. Customers who require development of a new information system usually do not understand the importance of information from the actual user of the system. After the market staff has a very good new product idea, it is also self-conscious of the interest of the product users. However, collecting demand directly from the actual user of the product has an irreplaceable necessity. Through the survey of 8 3 80 items, the most important reason for the failure of project failure is the lack of user participation and incomplete demand and incomplete specification (Standish 1995).
A part of the problem of demand is caused by confusion of different levels (business, users, functions). G E R H A r D illustrates some business needs, but he does not describe user needs because he is not the actual user of the "chemical tracking system". Only the actual user can describe the tasks they must use by this system. But they can't point out all specific functional needs of these tasks.
This chapter shows the relationship between customers and developers, which is extremely important to the success of software project development. I recommend writing a software customer demand right book and the corresponding software customer demand obligations to emphasize the importance of customer (and actual users) to participate in demand development process.
2.1 Who is customer
Usually, customers refer to individuals or organizations that are brought directly or indirectly obtained from the product. Software customers include people who have made requests, payments, selection, specifically or using software products (S T a K E H O L D E R) or those generated by the product.
G E R H A R D represents such customers of payment, procurement (P R O C U r e) or investment software products, is obliged to indicate business needs. They should clarify the high level of product and the main content of the product will be released. In Chapter 6, discussing business needs should explain the goals required by customers, companies, and users who want to profit from the system or users from the system. Business needs have established a guided framework for successive work. Any other description should follow business needs, but business needs cannot provide developers to provide many development descriptions needed. Next layer requirements - User needs - must be collected from users who use the product. Therefore, these users (commonly referred to as end users), constitute another software customer. They can say what tasks and some non-functional features should be used to use this product, and these features are important to enable users to receive products with this feature.
Note Customers who have business needs sometimes try to replace users, but usually they cannot accurately explain user needs. Because of the development of information systems, contracts (C O N T R A C T) or customer application, business needs should come from risk bearers, and user needs should come from the real use of the product, operator.
Unfortunately, these two customers may feel that they do not have time and (collection, analysis and writing requirements) demand analysts discuss. Sometimes customers also want analystists or developers to speak user needs without discussing and writing documents. Do not do this unless the demand encounters is extremely simple. If your organization wants the software to succeed, it must spend a few days to eliminate the embarrassing place in the demand and some aspects that make the program people feel confused.
Some of commercial software developments are somewhat different, because usually their customers are users. As the customer agent such as the Market Department, I may want to determine what the buyer of software products will like. But even commercial software, the actual user should participate in the process of collecting demand (Chapter 7 will talk). If you don't do this, the product is likely to have a lot of hidden dangers due to the lack of information provided by users.
2.2 Corresponding relationships between customers and developers
Excellent software products are based on excellent demand. High quality demand is derived from effective exchanges and cooperation between customers and developers. Typically, developers are associated with customer or customer agents, such as market employees, will become an opposite relationship. The managers of both sides only want their own interests and put on the needs of users to produce friction. In this case, they will not bring a little benefit to both sides.
Only when both participants understand what they need to succeed, but also know what to successfully serve the partners to establish a relationship. Due to project pressure and increasing increase, all risk bearers have a common goal. This is easy to be forgotten. In fact, everyone wants to develop an excellent software product that can be achieved without both business value, but also meets users.
Software customer needs rights list list ten legal requirements for customers in the implementation of the project demand projects and analysts and developers. Each right corresponds to software developers, analysts' obligations. Software customer demand obligations also list ten obligations on customers in the demand process. If you prefer, you can use it as the development of the developer.
Software customer needs rights book customers have the following rights: 1. Require analysts to use the expression of customer language habits. 2. Require analysts to understand the business and goals of the customer system. 3. Requires analysts to organize the information described during the acquisition period, and write software demand specifications. 4. Require developers explain the results of the work produced during the demand. 5. Require developers to maintain and maintain a job of cooperation throughout the exchange. 6. Require developers to provide suggestions for the implementation and demand for products, and take out your mind. 7. Describe the product to have easy-to-use, easy to use features. 8. Adjust your demand, allowing you to retrounce existing software components. 9. There is a true and credible assessment of the cost, affecting, and derived (T R A D E - O FF) when it is necessary to change the demand. 10. A system that meets customer functions and quality requirements, and these requirements are agreed by developers.
Software customer demand compulsory compulsory customers have the following obligations: 1. Professional issues such as the analysts explain their business and instructions. 2. Take time clearly explain the demand and constantly improve. 3. When you illustrate the system requirements, strive to be accurate. 4. Do you need to make decisions in time when needed. 5. To respect the cost estimation of developers and the feasibility analysis of demand. 6. Divide priority for single requirements, system characteristics, or use instances. 7. Review demand documents and prototypes. 8. Once you know to change the project requirements, you should contact the developer immediately. 9. When the demand change is required, it should be handled in accordance with the development process determined by the development organization. 10. Respect the process (procedure) used in the demand engineering. These rights and obligations can be applied directly to customers when developing software for internal groups. This also applies to those who have contractual relationships or have a clear customer collection. The development of universal market products, these rights and obligations are more suitable for client agents like the marketing department.
As part of the project plan, customers and developers should review the above two lists and reach a consensus. Some very busy customers may not be willing to actively participate in the demand process (that is, they don't accept software customer demand obligations), and lack of customer participation will likely lead to unsatisfactory products. Therefore, we must ensure that major participants in demand development understand and accept their obligations. If you encounter differences, by negotiation to achieve mutual understanding of your respective obligations, this can reduce future friction (such as one party and the other party is not willing or not satisfying the requirements).
2.2.1 Software customer needs rights
Right # 1: Requires analysts to use the expression demand discussion of customer language habits should focus on business needs and tasks, so use business terms, you should teach the analyst, and you don't have to know the computer's industry terminology.
Right # 2: Requires analysts to understand customers' business and goals to obtain user needs by communicating with users, analyzers can better understand your business tasks and how to make the product better to meet your needs. This will help developers to design outstanding software that truly meet your needs and reach your expectations. To help developers and analysts, you can consider how to invite them to observe you or your colleagues. If the new development system is used to replace the existing system, then developers should use the current system, which will help them understand how the system is working, and their workflow is available.
Right # 3: Requires analysts to write software requirements Specifications Description analysts to organize all the information you have obtained from you and other customers to distinguish business needs and specifications, functional requirements, quality objectives, solutions, and other information. A software requirements specifications can be obtained by these analyzes. Software requirements Specifications Software Requirements Specification, SRS) A protocol is reached in the development of product content between developers and customers. S R s can be organized in a manner that you think is easy to read and understand. To review the specifications written to ensure that they accurately express your needs. A high-quality software demand specification can help developers to develop genuine products.
Right # 4: Requires the results of the demand work description The analysts may adopt a variety of charts as a supplement to the textual software requirements specifications. Since the chart like a workflow chart can clearly describe certain aspects of system behavior. So the various charts in the demand description have a very high value. Although they are less difficult to understand, you are likely to be unfamiliar with this. Therefore, analysts can be required to explain the role of each chart or other needs development results and symbols, and how to check the chart has no error and inconsistency.
Right # 5: Require developers to respect your opinion If the user and developers cannot understand each other, the discussion about the demand will have obstacles, and cooperate together to 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 the success of the project. Similarly, customers should also demonstrate their efforts to respect and gratitude to the developers' efforts to successfully go to the project.
Rights # 6: Require developers to provide recommendations for demand and product implementation, to take out ideas, "demand" said by customers is a practical implementation solution, and analysts will try their best to understand the true. Business and their needs, while also identifying existing systems that are not suitable for current services to ensure that the product will not be invalid or inefficient. After thorough understanding things in the business sector, analysts sometimes make considerable improvement methods. Experienced and creative analysts can also propose a very valuable system characteristic that some users have not found. Right # 7: Describe the features of the product easy to use You can ask the analyst to focus on software ease of use while achieving functional needs. Because these easy-to-use features or quality properties make your task more accurate and efficiently. For example, customers sometimes require products to "user friendly" or "robust" or "high efficiency", but this is too subjective for developers. The correct thing should be: Analysts understand the specific characteristics contained in the customer's friendly, strong and efficient, and will discuss it in detail in Chapter 11, by inquiry and investigate.
Right # 8: Adjustment needs, allowing reusability of existing software components to usually have certain flexibility. Analysts may find that some software components are very consistent with the needs you describe. In this case, analysts should provide some options to modify demand so that developers can reuse some existing software in new system development. If there is a reusable opportunity to appear, you can adjust your needs, you can reduce costs and save time, without having to be developed in strict accordance with the original needs. So, if you want to use some existing business common components in your product, they are not fully fitted with the features you need, and the flexibility in a certain extent is extremely important.
Rights # 9: Requires the trusted assessment of the change in the change, sometimes people face better, more expensive programs, will make different options. At this time, it is necessary to evaluate the impact of demand changes, it is necessary, so you have the right to make developers to give an indexed and credible assessment, including influence, cost and loss. Evaluation. Developers cannot exaggerate assessment costs because they do not want to implement changes.
Rights # 1 0: The system that meets the customer's function and quality requirements, everyone wants the project to succeed. But this not only requires you to clearly tell the developer's concerns about the system "what" what "do, but also asked developers to understand clear and restrictions through communication. Be sure to express your assumptions and potential expectations. Otherwise, the product developed by developers is likely to be unable to satisfy you.
2.2.2 Software Customer Demand Officer
Obligation # 1: Explains your business analyst to the analyst to rely on your business concept and terminology to explain them. But you can't expect analysts that will become experts in this area, but only let them really understand your problems and goals. Don't expect analysts to grasp the subtle and potential of your business, they are likely to not know "common sense" for you and your colleagues.
Obligation # 2: Take time clearly, and improve the demand customers are very busy, often participate in demand development when they are most busy. But in any case, you have an obligation to take the time to participate in the discussion of the "Brain Storm" meeting, accept interviews or other activities that get demand. Sometimes analysts may first think that you understand your point of view, and you will need your explanation. At this time, please patiently treat some demand and demand for the refining process, because it is a natural phenomenon in people exchange, not to mention the success of software products.
Obligated # 3: Accurate and detailed description requirement to prepare a clear, accurate demand document is difficult. Since the problem of processing details is not only annoying and time-consuming, it is easy to leave ambiguous demand. However, this kind of fuzziness and inaccuracy must be resolved during the development process. And you are just the best candidate for solving these problems. Otherwise, you have to rely on developers to correctly guess.
The logo of TO BE DETERMINED, TBD is a good way to be temporarily added in the demand specification. This flag can be used to indicate which needs to further explore, analyze, or increase information. However, sometimes it is also because a particular demand is difficult to solve or not to deal with the T b D logo. Try to explain the contents of each demand so that analysts can accurately write it into software requirements specification. If you can't express it, you have to allow the necessary accurate information such a process. The so-called prototype technology is usually used. Through the development of the prototype, you can repeatedly modify with developers and constantly improve the demand definition. Obligation # 4: Timely decision is as an architect to build a house for you, and analysts will ask you to make some choices and decisions. These decisions include processing methods from multiple users or select compromise in quality characteristics conflicts and information accuracy. Customers who have the right to make a decision must be actively treated, do it as soon as possible, make decisions. Because developers usually only have to make a decision to act, this waiting will delay the progress of the project.
Obligation # 5: Respecting developers' needs feasibility and cost assessment All software features have their cost prices, developers are best suited for budget (although many developers are not good at assessing forecasts). Certain product features you want may not be unconventional in technology, or achieve it to pay extremely high cost. And some needs are trying to require unlight performance in the operating environment or try to get some fundamental data, developers will negatively evaluate this, you should respect their opinions.
Sometimes, you can reappear a technical feasible, cheap demand, for example, requiring a behavior that is incapable in "instant", but the changing more specific time demand statement ("at 5 0 ms) Within "), this can be achieved.
Obligation # 6: Demand Demand Priority Most items do not have enough time or resources to achieve each detail of functionality. Decide which features are necessary, which is important, which is good, is the main part of demand development. Can only be responsible for setting up demand priority because developers are not possible to decide the needs priority according to your point of view. Developers will determine the priority to provide information about the cost and risk of each requirement. When you set a priority, you help developers ensure the best results in the appropriate time in the appropriate time.
Under time and resource limitations, the desired characteristics should be completed or completed should respect the developer's views. Although no one is willing to see what you want is not implemented in the project, it is necessary to face this reality. Business decisions sometimes have to narrow the project or extend during the project, or increase resource, or in quality.
Obligation # 7: Review Demand Documents and prototypes As we will discuss in Chapter 1 4, whether it is formal or informal, review the demand document will help the software quality. Let customers participate in the review to truly identify whether the demand document is indeed complete, correctly explaining the desired necessary characteristics. The review also provides a chance to the customer representative to bring feedback to the needs analysts to improve their work. If you think the demand document written is not accurate enough, you have an obligation to tell the analyst as soon as possible and advise the improvement.
By reading the requirements specifications, it is hard to imagine what the actual software looks like. A better way is to develop a prototype for the product. This way you can provide more valuable feedback to developers to help them better understand your needs. It must be recognized that prototype is not an actual product, but the developer can transform it and expand its successful system.
Obligation # 8: There is a change in demand to meet the constant demand change immediately to complete the high quality products in the scheduled plan to bring serious negative impacts. Change is inevitable, but the more changes in the development cycle, the greater the influence. Changes will not only lead to extremely high costs, but also forced delays, especially when the general structure has been completed, it needs to increase new features. So once you find that you need to change the needs, you must immediately notify the analyst. Obligation # 9: The process of developing the development of organizations should be changed to minimize the negative impact of changes, all participants must follow the change control process of the project. This requires not abandon all proposed changes, analyzes each of the requirements, considers, and finally makes appropriate decisions to determine the import of certain changes to the project.
Obligation # 1 0: Respect the demand engineering process used by developers
The most challenging in software development is to collect demands and determine their correctness. The methods used by analysts have their rationality. Maybe you think the demand process is not cost-effective, but please believe that the time to develop in demand is "very price". If you understand and support the analyst to collect, write demand documents and ensure that the technology adopted by the quality, the entire process will be more smooth. Although you ask the analyst why they want to collect some information or participate in activities related to demand.
2.3 "Signing" means
Signing an agreement for the needs of the developed product is an important part of the relationship between customers and developers. Many organizations use the concept of "Signing" in a demand document as a sign of the customer's agreement. Therefore, all demand participants must really understand the meaning of "signing".
But there is such a problem: the customer representative often regards "signing" as meaningless. "They want me to sign the name under the last line of paper, so I signed it, otherwise these developers do not start coding." This attitude will bring trouble in the future, such as customers want to change demand or product Dissatisfaction. "Yes, I signed the name on the needs, but I didn't have time to read all the content. I believe you, you are not to let me sign."
The same problem also happens on the administrators who use only the contract as the executive of the completion document. Once there is a demand change, he pointed to the software demand specification: "But you have signed it on a demand, so these are what we have to develop. If you want anything else, you should tell us earlier. "
Such attitudes are not right, it is impossible to understand all the needs in the early days, and there is no doubt that the demand will change. Signing on demand is the correct way to terminate the demand development process. However, participants must understand what their signing means.
More importantly, the signature is based on a baseline of a demand agreement, so the signing of the demand specification should be understood: "I agree that this document shows the current understanding of the demand for the project. Further change can be This baseline is performed through the change process of the project definition. I know that the change may enable us to re-negotiate costs, resources, and project duration tasks.
About baseline reaching a certain consensus will be easy to endure future friction, these friction derived from the improvement of the project and the error of the demand or new requirements for market and business. It will help you form a continuous and good customer relationship with the initial demand development work. The relationship between customers and developers has laid the foundation for the success of the project.
Next: • Let customers provide the project's business needs and user needs. What are the entries for the rights books and the obligations, which are accepted and understood by the customer? What is it? • Discuss your rights and obligations with your important customers to achieve an agreement and put it into practice. These behaviors will help customers and developers understand each other to form a more harmonious relationship. • If you are the customer participants in the software development project, you feel that your needs rights are not fully respected, you can discuss the contents of the title with the leadership or business analyst of the software project. To build a work relationship of cooperation, we must try our best to satisfy your obligations to your obligations.
