Transfer from ( http://www.blogjava.net/cssseek/archive/2010/11/08/337444.html )
Boil hard for a few months, software development finally came to an end soon. System function has been basically completed, step by step in preparation for the completion of the final test, the customer suddenly proposed to change some of the non-functional requirements. This software development team, no less than sunny thunder, this is for all software developers are one of the most terrible thing. Because in most cases, changes in non-functional requirements of the system will evolve into a process of endless changes, the end customer will be dragged into the quagmire and development team are difficult to extricate themselves.
Changes in customer demand for power should be, If that is the need to change, of course, to meet customer needs. But the problem is not to change the abuse of power, some trivial changes to the non-functional requirements used to develop a glamorous pet changes. For the non-functional needs of customers there are always new ideas, the project never seems no way to end. When this happens before, I felt quite depressed and felt very unfortunate, how customers will run into this. Can read the "fine solution design patterns (Design Patterns Explained)" passage from the book, I suddenly realized that this is not my fault, but it was the world like this, ah, never change is change.
Disturbing changes in the non-functional requirements
In software development, we will encounter such a problem: the customer a new idea to overthrow the previous discussion with the customer through the repeated demand for recognition laid down. If the functional requirements but also makes it easier to accept change, after all functional requirements are not realized, will greatly affect the quality of software products. But now I am responsible for this development are encountered in some non-functional change, but many seem irrelevant, trivial changes.
(1) What non-functional requirements?
In the IEEE, the software requirements are defined: the user needed to solve problems or achieve goals condition or function. Typically includes business requirements, user requirements, functional requirements, industry requirements and implied needs of some non-functional. Reflect the business needs of customers on the system, the product high-level objectives and requirements; functional requirements definition, the developer must implement software features. The so-called non-functional requirements, is to meet the needs of the user business functional requirements must have addition to other features. Including system performance, reliability, maintainability, ease of use and the business of technology and adaptability. The most common is the software interface, easy operation and a series of requirements.
(2) non-functional characteristics of requirements changes
Let's point of view and from the customer perspective of the developer to look at the characteristics of non-functional requirements. First, some small non-functional requirements from the customer perspective do not seem to work, but in fact developers have to spend a long time to complete these small features. Second, many non-functional requirements, such as beautiful interface and easy operation are all customers of a hot head, or leading the deployment of a racking our brains to go on demand, often in the requirements analysis phase of the original lack of attention to the content.
In fact, the non-functional requirements are often neglected or even ignored. Description of the reasons for non-functional requirements is difficult, it is difficult as the functional requirements as structured and quantified by the words to describe clearly. In describing these needs, we often use better software performance, operation to be convenient, nice software interface to the more obscure the description of such terms. For example, the ease of use to both art and UI related to the interface, ergonomics, interactive design, psychology, user behavior patterns and so on. Which describe the words are out of the software execution environment, is a description of the scene and the related, it is difficult to reflect the specific software architecture design and implementation.
Why are non-functional requirements change frequently occur?
Why are non-functional requirements can not be fixed down? Or allowed to settle down after down? Many people often ask this question. In fact, when he became a client, he may not ask this question.
(1) Non-functional requirements prone to understand differences
In the software requirements analysis phase, customers and developers of non-functional understanding of the needs presented "general consensus of many, many differences in detail" features. General knowledge with the analyst, background, as well as the standard level of client representation, the two sides exchange status. Even through repeated communication, but the practical experience to the needs of non-functional description is not always clear, not clear, mainly because at this stage is also called the product exists only in our conception of the brain.
As a customer, in most cases do not understand technology, but the software he needed was in his mind an impression of. Imagine he would look and function of the software, and then through oral or written way of telling the analyst. Simply put, that is, at this stage the user often can not define exactly what they need. Users often think they know, but in fact they made the demand just based on the current work requirements, or they imagine things. The result is when a customer needs analysis officer to demand, often through their own natural language to express ideas, so that the expression of the results of the demand for real is just a description, or even just a description of an angle, but This description is far from guaranteed to be one hundred percent correct understanding.
When the customer request, both sides understand that there is no disagreement about the time developers began to work. But with the development work progresses, the system begins to show prototype, the customer's understanding of the system are gradual. This time, the customer will be the interface on the system, operation, features, performance and so have some understanding, it is possible to make changes in demand requirements, but many of these requirements are based on subjective, human factors. In short, the more they understand the new requirements will be more.
(2) there is no clear demand for change management process
Common sense in software development is not to indulge in the event of complaints needs to change, do not blindly go to meet the new demands of customers, but to manage and control requirements changes. Paradoxically, we often see the changes made, discussion and implementation often only lip service. This has two drawbacks: first, over time, either party or the development team said that change is not clear why the results occurred and how kind. Obviously, this is in improving the quality of projects to improve the development process is very negative. Second is the lack of formal constraints and quantitative analysis of changes in costs, changes will be made very arbitrarily, or hastily implemented, will greatly affect the quality of the project's progress and development.
Therefore, there is no clear demand for change management process, and it will demand changes to become rampant. Because not all changes have to change, not all changes have to immediately modify, change management needs to decide what the purpose is to change the type of when and what changes need to be modified. Style issues such as the interface to connect to not modify, or planning about the time change until after the optimization.
(3) did not let customers know the cost of requirements changes
Not assessed the impact of the change needs to change is the root cause of flooding. Is a price change should be changed to assess the costs and needs to let customers know the consequences of change. If the client does not know the price changing needs of the developer's hard work will be difficult to understand.
Compared to the needs of developers, customers may demand changes to lack of knowledge, that they pay for the software development team will service it. Therefore, changes in customer demand will often unscrupulous bomb, the requirements change as a trifling matter, with random changes in demand for personal preferences. So, in and pick out customer contact should be the attitude, especially needs to let them know the costs caused by random changes and risks. If the customer that the price for too much, then the developer does not need to be revised, according to the original schedule to go, but still record changes, the next version to be modified.
How to effectively control the non-functional requirements change?
Before making any changes, we must consider the consequences. Because non-functional requirements change in the development of the important position which, if needs change, the impact is very broad. Therefore, effective control of non-functional requirements is a frequent change things can not be overlooked.
(1) to establish a clear baseline of non-functional requirements
For software development, the change is inevitable, there is no way to escape, only a positive response. Therefore, in the development process, establish a clear baseline of non-functional requirements is an important thing. If you did not do a good job of non-functional requirements, the scope of the baseline ambiguity, it is easy to be clients to seize the loopholes, often have to pay a lot of unnecessary changes. If the non-functional requirements baseline well, clear and have customers sign the document, then the latter's non-functional customer requirements change will be greatly reduced. Therefore, when establishing the baseline demand must not be soft, this is not to deliberately targeted customers, but does not allow customers to develop the habit of frequent changes, or end of trouble.
(2) the establishment of requirements change management process
Success or failure of software development requirements change have important implications, we can not refuse to change the requirements of customers can not blindly accommodate customers, it must be good demand for change control. There is a popular saying was very good: demand control of change management is not intended to change the place, but to manage change to ensure that changes in an orderly manner. Requirements change management process, including change request links, approval officers, approval, approval processes.
The purpose is twofold: First, the placement of the change process as much as possible standardized, to reduce the mouth to the non-necessary non-emergency, non-rational, non-senior management changes intended to invalid. The second is to leave a written basis for possible future changes in cost accounting account is ready. So, who have not traveled to perform the change approval process, all changes are invalid will not be accepted. In practice, people often do not want to change the demand for small to perform formal requirements management process that reduces the efficiency of development, a waste of time. But precisely because of this concept will need to change so that gradually becomes uncontrollable, leading to project failure.
(3) to confirm whether the customer accepts the price changes
Unplanned demand changes as a risk certainly exists on the impact of the project, but the size difference. And customers are never satisfied, may appear every day, in order to control the demand for frequent changes. Changes resulting from the need to evaluate and quantify the costs, an analysis report was submitted to both leaders. Otherwise, the compromise will allow the project blindly further deterioration. Therefore, let the customer know that change is a price, do not allow customers to develop a free to change the problems. Generally, if the customer that the non-functional change is necessary, racking our brains and not their superiors would accept the proposed price. Through communication and consultation with clients, the team will not be incurred even without the return of the customer complained.
(4) strengthen contract binding
Although the software development contract signed is difficult to precisely define the beginning of each demand, the contract alone is not helpful, but it can not ignore the contract binding. Because sometimes the sales staff to enable customers to quickly sign a contract, often hasty decisions and customer demand for one-sided agreement. When a new customer demand, sales staff often saw "should" is only a small change, there is not much that could be a direct promise to change. Therefore, signing development contracts with customers, you can increase the number of relevant terms, such as limited time, customer needs change to require changes in circumstances acceptable to refuse to accept or partially accepted, you can also change provisions in the demand for change must be performed control processes.
(5) to strengthen feelings of communication and attention to communication skills
Most of the time the contract binding alone can not solve the dispute. Customers anxious is a subtext: do not do it, do not want to get out, are plenty of companies want to do. For example, sometimes obviously unreasonable request, but customers will quibble Why not give them to do, and this is within the scope of the contract work. So, just look at the contract is of no use.
That how to do it? The usual practice is through the feelings of contact for customers sympathy. We often say a commonplace to customers, then that demand should also pay attention to mention reasonable, these words in the change management has a unique meaning. Line with our words is: do a good job requirements change management control only half of the work, as well as half of the work is to reason, to heart, with emotion to persuade customers to return.
May also wanes, ebb and flow. Change does not always give us trouble, and sometimes surprises. In software development, treatment of the client's non-functional requirements change, we need to look at an ordinary, not blindly reject, and do not blindly agree.