Non-functional requirements change for software development

Demand change should be the customer's power, if it is necessary to change, of course, to meet customer needs. But the problem is not to allow the change of power abuse, some irrelevant non-functional requirements change spoilt to form an imposing change. For non-functional requirements customers will always have new ideas, the project seems to have no way to end. In the past when this happened, I always feel very frustrated, feel very unfortunate, how to meet such customers. Can be read in the "design mode of fine solution (designing Patterns explained)" A book of a passage, I suddenly understood that this is not my fault, the world is the original, Ah, is always unchanged is change.

Annoying non-functional requirements Change

In software development, we all encounter the problem: a customer's new idea, will overturn the previous and customer after repeated discussions and confirmed the requirements. If the functional requirements change will be easy to accept some, after all, functional requirements are not implemented, it will greatly affect the quality of software products. But now I am in charge of the development project encountered are some non-functional changes, and many are seemingly insignificant, trivial changes.

(1) What is the non-functional requirement?

In IEEE, software requirements are defined as the conditions or functions that a user needs to solve a problem or achieve a goal. Generally includes business requirements, user needs, functional requirements, industry implied requirements and some non-functional requirements. Business requirements reflect the customer's requirements for the high level of the system and products; Functional requirements define the software features that developers must implement. The so-called non-functional requirements, is to meet the user's business needs, in addition to the functional requirements of the characteristics. Including system performance, reliability, maintainability, ease of use and technology and business adaptability. The most common is the software interface, easy to operate a series of requirements.

(2) The characteristics of non-functional requirements change

Let's look at the characteristics of non-functional requirements from a customer perspective and a developer's perspective. First of all, some non-functional small requirements from the customer point of view of the workload is not, but in fact, developers spend a relatively long time to complete these small functions. Secondly, many non-functional requirements, such as the interface is beautiful, easy to operate and so on are the customer's mind a hot, or the leadership of a pat head on the deployment of the demand, often in the requirements analysis phase is not attention to the content.

In fact, non-functional requirements are often overlooked, or even neglected. The reason is that non-functional requirements are difficult to describe, and it is difficult to describe them in terms that are structured and quantified, like functional requirements. When describing this kind of demand, we often use the software performance is good, the operation is convenient, the software interface should be beautiful and so the more vague descriptive words. For example, ease of use involves both graphic and UI interfaces, human-computer engineering, interactive design, psychology, user behavior patterns, and more. This kind of descriptive words are separated from the software implementation environment, is the description of people and related scenarios, it is difficult to reflect the software architecture design and specific implementation.

Why are non-functional requirements changes occurring frequently?

Why can't non-functional requirements be fixed? or set it down and not change it? There are usually many people who ask such questions. In fact, when he becomes a client, he may not ask the question.

(1) Non-functional requirements easily produce understanding differences

In the phase of software requirement analysis, the understanding of non-functional requirements of customers and developers presents the characteristics of "more consensus, more details." Generally with the knowledge of the analyst, background, as well as the standard level of customer statements, the communication between the two sides. Even through repeated communication, the description of non-functional requirements in practical terms is never clear enough, mainly because at this stage the so-called product is only in the minds of everyone.

As a customer, most of the cases do not understand the technology, but he needs the software in his heart still have an impression. He imagines the look and function of the software and then tells the demand analyst verbally or in a written way. Simply put, it is at this stage that users are often unable to define exactly what they need. Users often think they are aware of it, but in fact their demands are based on the current job or what they imagine. The result is that when customers demand analysts, often through their own ideas in natural language to express, such an expression of the actual demand is only a description, or even a description of a certain angle, but far from ensuring that such a description can be fully understood correctly.

When the client asks, the developer begins to work when the two sides think that there is probably no disagreement. But along with the development work unceasing progress, the system began to show the embryonic form, the customer to the system understanding also gradually depth. At this time, the customer will have some understanding of the system interface, operation, function, performance and so on, it is possible to propose requirements change requirements, and many of these requirements are based on subjective, man-made factors. In short, the more they learn, the more new requirements will be.

(2) No explicit requirements change management process

The common sense in software development is that once there is a need to change, do not blindly complain, do not blindly to meet the new needs of customers, but to manage and control changes in requirements. But it is puzzling that we often see that the presentation, discussion and execution of changes are often only verbal. There are two drawbacks: the first is a long time, both the parties and the development team are not clear about what happened and how the change occurred. Obviously, this is bad for improving the quality of the project and improving the development process. Secondly, due to the lack of formal constraints and quantitative analysis of the cost of change, changes will be very casually proposed, or be hastily implemented, will greatly affect the progress of the project and the quality of development.

As a result, there is no clear requirement change management process, which will make the demand changes become rampant. Because not all changes have to be modified, and not all changes are immediately modified, the purpose of change management is to determine what types of changes need to be modified and when. For example, the interface style problem, you can first do not modify, or plan the modified time until later to optimize.

(3) Failure to let customers know the cost of changing requirements

The impact of the change is not assessed as the root cause of the flood of demand changes. Changes are costly, and the cost of change should be assessed and the customer should be informed of the consequences of the change in requirements. If the customer does not know the cost of changing the requirements, the developer's hard work will be difficult to understand.

Customers may be less aware of requirements changes than demand developers, and the software development team will serve them as they pay. Therefore, customer changes in demand will often be no bogey, will change the requirements of joke, with personal preferences to change the needs of the random. Therefore, in contact with customers should be a clear attitude, especially to let them know the requirements of random changes in the costs and risks. If the customer thinks the price is too great, then the developer will not need to modify it in time, but still record the change until the next version is modified.

How to effectively control changes to non-functional requirements?

Before making any changes, we have to consider the consequences. Because of the important position of non-functional requirement change in development, the impact is very wide once the demand changes. Therefore, effective control of non-functional requirements frequently change is a matter that can not be overlooked.

(1) Establish a clear and non-functional requirements baseline

For software development, change is unavoidable, and can not escape, only positive response. Therefore, it is important to establish a clear, non-functional requirements baseline during the development process. If non-functional requirements do not do well, the baseline range is ambiguous, it is easy for customers to seize the loophole, often to pay a lot of unnecessary changes. If the non-functional requirements baseline is done well, the document is clear and the customer is signed, then the non-functional requirements changes made by the later customers will be greatly reduced. Therefore, in the establishment of the demand baseline must not be soft, this is not to deliberately target customers, but can not allow customers to develop the habit of constantly changing, otherwise endless.

(2) Establish requirements change management process

The requirement change has the important influence to the software development success or failure, neither can reject the customer's change request completely, also can not blindly indulge the customer, therefore must need to do well the demand change control. A popular saying is very good: the purpose of change management is not to control the occurrence of changes, but to manage the change, to ensure that changes in an orderly manner. The requirements change management process includes the change application link, the approving person, the approval item, the approval process and so on.

There are two purposes: one is to standardize the process of changing the customer as much as possible, to reduce the unnecessary, non-emergency, unreasonable, and non-executive intention of the open mouth. The second is to leave the written basis for possible future cost accounting ready to change account. Therefore, any failure to perform the examination and approval procedure changes, all are invalid change is inadmissible. In practice, people are often unwilling to implement the formal requirements management process for small changes in demand, which reduces development efficiency and wastes time. But it is precisely because of this idea that changes in demand will become uncontrollable, resulting in the failure of the project.

(3) Confirm that the customer accepts the price of the change

Requirements change as an unplanned risk to the project must have impact, but the size of the difference. And customer demand is never satisfied, may be the same day, in order to achieve control of frequent changes in demand. The cost of the change will need to be assessed and quantified to form an analysis report submitted to both leaders. Otherwise, the compromise will only make the project worse. Therefore, to enable customers to realize that changes are a cost, do not allow customers to develop the problem of arbitrary change. In general, if the customer believes that the non-functional change is necessary, rather than the head of his or her superiors, it will accept these costs. Through communication and consultation with customers, the development team will not incur customer complaints even if there is no return.

(4) Strengthening contract binding force

Although it is difficult for software development contracts to accurately define each requirement at the beginning of a contract, it is not helpful to rely on contracts alone, but it cannot ignore the binding force of contracts. Because sometimes the sales staff to enable customers to sign contracts quickly, often hasty decision and one-sided consent to the needs of customers. When customers put forward new requirements, salespeople often see "should" is only a small change, not too much impact, may be directly promised to change. Therefore, when signing a development contract with the customer, you can add some relevant provisions, such as limiting the customer to propose changes in the time, specify the circumstances of the changes can be accepted, rejected or partially accepted, can also be required to change the need to carry out changes in the control process.

(5) Strengthen emotional communication, pay attention to communication skills

Most of the time, the contract alone cannot resolve the dispute. Customer worry is a subtext: do not do, do not want to go away, want to do a lot of companies. For example, sometimes it is unreasonable to ask, but customers will also argue with what not to do for them, this is within the scope of the contract work. Therefore, it is useless to look at the contract alone.

What can I do? The usual practice is through emotional contact, to win customer sympathy. We often say to customers a cliché, is to mention the need to pay attention to reasonable, this sentence in the change management has a unique significance. In our jargon is: do a good job change management control is only done half of the work, and half of the work is to reason, to intentions, with feelings to persuade customers back.

The moon is cloudy, the tide rises and falls. Change does not always bring us trouble and sometimes surprises. In the software development, treats the customer to propose the non-functional demand change, we need to treat with the ordinary heart to look, is not blindly refuses, also does not blindly agree.