How to deal with software development, non-functional requirements change?

2010-11-09  来源:本站原创  分类:Development  人气:135 

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.

相关文章
  • Telecom Software Development Flex will bring change? 2010-03-01

    If you are a programmer telecommunications industry, famous topology tools TWaver You must be familiar; but if you mention TWaver think of a Swing component package, you no doubt already out of. After ten years of development, TWaver look is no longe

  • How to deal with software development, non-functional requirements change? 2010-11-09

    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 completio

  • "Software development project needs to change factors" questionnaire, a lot of friends, please support! 2011-02-22

    In this study, using the "send survey" network design of the questionnaire a "software development project needs change factor," the anonymous survey. Survey based on PMBOK PMBOK, CMM model, and software requirements management book an

  • The process of software development stage 6 2009-11-11

    The process of software development stage 6 Plan Of the problem to be solved by a general definition, including the understanding of user requirements and reality, from a technical, economic and social factors, such as three aspects of research and d

  • Successful Software Development 2010-02-03

    successful software development (the original book version 2) Author: (United States) Scott E. Donaldson, Stanley G. Siegel Translator: Liu Li-Chung Tian, M. out Price: 45.00 yuan Publisher: China Machine Press ISBN :978-7-111-29423-8 Summary: This s

  • Software development project implementation and progress of management control 2010-10-28

    Information technology and modern management science knowledge and the rapid development and rapid spread, making the government , enterprises are increasingly strong demand for IT applications and harsh, but can not ignore the fact that it is "softw

  • 5 minutes to teach you about the most popular method of software development 2010-08-01

    Waterfall model-Waterfall Waterfall model into the software life cycle planning, requirements analysis, software design, programming, software testing and operation and maintenance of the six basic activities, and provides for their top-down, the int

  • Software development and progress of implementation of the project management control 2010-10-28

    Information technology and modern management science knowledge and the rapid development and rapid spread, making the government , enterprise IT applications, increasing demand for strong and harsh, but can not ignore the fact that it is "software pr

  • An iterative development of the research: the risks of software development 2011-09-29

    Our software development there is a huge risk when we went through several months of hard work will find that our software is not software customer satisfaction. This often happens when several situations: 1 prick began to frequent customers, the dem

  • Software development summary 2009-05-05

    Needs to give you some non-functional (or quality) requirements of the example? If customers require high performance, the use of extremely high degree of convenience and security, you will give him any suggestions? Can you give some to describe the

  • Finishing the principles of software development knowledge 2009-08-30

    Finishing the principles of software development knowledge Maintainability Support System (Maintainability), to enhance reusability of the system (Reuseability) ---------------------> For object-oriented software system design is a core issue. 1. The

  • Software development management best practices - on build and continuous integration 2009-09-11

    XP approach to software development as on building a best practice management; agile software development is also to ensure continued integrated software as a matter of principle the success of the project. Coincidentally, 2003 China's software ( 600

  • Software development projects Experience of risk management 2009-09-30

    Involved in large-scale software projects will realize that many things can go wrong, but mistakes can be a project can be adversely affected, loss or other adverse effects. In the project risk is a series of events or the possibility of adverse resu

  • Project Management System (software): software development projects. Research 2009-10-13

    Project Management System and Project Management Software slightly different; the former is generally customized, including the industry, or for a certain area, or even specific customer needs; which is generally more common in nature, or only the pr

  • Experience on software development 2010-02-22

    Year seldom log, more to the project development and research experience and knowledge of others. Development of 4 years to do, give me an overall feeling is pain and happiness with. I believe many of my friends and I like to solve a difficult proble

  • Software development: requirements analysis, rule 20 2010-05-23

    Xing Xuehui / (IT managers in the world) For business users, they followed hundreds of suppliers, in front of thousands of consumer customers. How to use complicated software management provider and consumer customers, how to do fine in a small packa

  • Learning needs of software development - software development, requirement analysis, rule 20 2010-06-02

    On business users, they followed hundreds of suppliers, in front of thousands of consumer customers. How to use complicated software management provider and consumer customers, how to do fine in a small package into the sauce, sale, transfer, deposit

  • Comparative analysis of commonly used software development model 2009-12-28

    As everything else, the software also has its birth, the birth, growth, maturity and decline of the survival process, generally referred to as "software life cycle." Software life cycle is generally divided into six stages, namely planning, requ

  • Software development, these documents do you use the 2010-01-14

    As we all know, the purpose is to make the software to meet customer needs, the requirements include functionality, appearance, operation, time and performance and other aspects. So, in the software development process the most important part of it,

  • Little experience of software development 2010-02-22

    Year seldom log, more to the project development and research experience and knowledge of others. Developed four years to do, give me an overall feeling is pain and happiness with. I believe many of my friends and I like to solve a difficult problem