How can software development cope with changes to non-functional requirements?

From: http://www.uml.org.cn/RequirementProject/201009293.asp

 

After a few months of hard work, software development is coming to an end. The system functions have been basically completed. When preparing to complete the final test step by step, the customer suddenly proposed to change some non-functional requirements. This is no less shocking for the software development team, and it is also one of the most terrible things for all software developers. In most cases, changes to non-functional requirements will evolve into an endless modification process for the system. In the end, both the customer and the development team will be dragged into the quarary and hard to extricate themselves.

Demand change should be the power of the customer. If it is necessary to change, of course, to meet the customer's needs. However, the problem is that changes cannot be abused, and some irrelevant non-functional demand changes cannot be favored. There will always be new ideas for non-functional customers, and there seems to be no way to end the project. In the past, when this happened, I always felt very frustrated and felt very unfortunate about myself. How can I meet such a customer. After reading a passage in design patterns explained, I suddenly realized that this is not my fault. The world is like this, and what remains unchanged is change.

 

Annoying changes to non-functional requirements

In software development, everyone has encountered this problem: the customer's new idea overturned the requirements that have been confirmed after repeated discussions with the customer. Changes to functional requirements will make it easy to accept. After all, the failure to implement functional requirements will greatly affect the quality of software products. But now I am in charge of this development project encountered some non-functional changes, and many are seemingly irrelevant, trivial changes.

 

(1) What are non-functional requirements?

In IEEE, software requirements are defined as the conditions or functions required for a user to resolve a problem or achieve the goal. It generally includes business requirements, user requirements, functional requirements, industry implicit requirements, and some non-functional requirements. Business Requirements reflect customers' high-level system and product objectives. Functional requirements define the software functions that developers must implement. Non-functional requirements refer to the features that must meet users' business needs except functional requirements. Including system performance, reliability, maintainability, usability, and adaptability to technologies and services. The most common requirements are software interfaces and convenient operations.

 

(2) features of changes to non-functional requirements

Let's look at the characteristics of non-functional requirements from the perspective of customers and developers. First of all, some non-functional small demands seem to have little workload from the customer's perspective, but in fact developers need to spend a relatively long time to complete these small features. Second, many non-functional requirements, such as beautiful interfaces and convenient operations, are the demands of customers who are eager to develop their minds, or leaders who are able to deploy their minds at a glance, it is often the content that was not paid attention to in the demand analysis phase.

In fact, non-functional requirements are often ignored. The reason is that it is difficult to describe non-functional requirements. It is difficult to describe the functional requirements clearly by using structured and quantified words. When describing such requirements, we often use vague descriptions such as good software performance, convenient operations, and elegant software interfaces. For example, ease of use involves both art and UI interfaces, human-machine engineering, interactive design, psychology, user behavior patterns, and so on. These descriptive terms are separated from the software execution environment and are used to describe people and related scenarios. Therefore, it is difficult to reflect the software architecture design and implementation.

 

Why do non-functional requirements change frequently?

Why can't non-functional requirements be fixed? Or will it not change after it is settled? Many people usually ask such questions. In fact, when he becomes a customer, he may not ask this question.

 

(1) non-functional requirements are prone to different understandings

In the software requirement analysis stage, customers' and developers' understanding of non-functional requirements shows the characteristics of "a wide range of consensus and many differences in details. It is generally related to the analyst's knowledge and background, as well as the degree of standards stated by the customer and the communication between the two parties. Even through repeated communication, the descriptions of non-functional requirements from practical experience are never clear or clear enough, this is mainly because the so-called products still exist in the minds of everyone.

 

As a customer, he doesn't know the technology in most cases, but he still has an impression on the software he needs. He will imagine the appearance and functions of the software, and then tell the demand analyst through verbal or written instructions. Simply put, users often cannot define exactly what they need at this stage. Users often think they are clear, but in fact their demands are based on the current work needs or what they think. The result is that when a customer asks a demand analyst, he or she uses natural language to express his or her own ideas. Such an expression is only a description of real needs, it is even a description from a certain angle, but it is far from guaranteed that such a description can be fully understood.

 

When the customer asks, the developers start to work when both parties think there is no difference in understanding. However, with the continuous development, the system began to show its prototype, and the customer's understanding of the system was also gradually deepened. At this time, the customer will have some knowledge about the system interface, operations, functions, performance, and so on, and may propose requirements for changes to requirements, many of these requirements are based on subjective and human factors. In short, the more they know, the more new requirements they will have.

 

(2) There is no clear demand change management process

In software development, the common sense is that once a demand change occurs, do not blindly complain or cater to the customer's new needs, but manage and control the demand change. But what is puzzling is that we often see that the proposal, discussion, and implementation of changes are often only verbal. There are two drawbacks to doing so: First, it takes a long time, and neither the client nor the development team can tell you why the change happened or how the result was. Obviously, this is very unfavorable for improving the project quality and the development process. Second, due to the lack of formal constraints and quantitative analysis on the cost of changes, changes will be proposed very casually or executed rashly, which will greatly affect the project progress and development quality.

Therefore, without a clear demand change management process, demand changes will become rampant. Not all changes need to be modified, and not all changes need to be modified immediately. The purpose of demand change management is to determine the types of changes that need to be modified and when to be modified. For example, if there is a problem with the interface style, you can leave it unmodified, or plan the modification time to be later optimized.

(3) The customer is not informed of the cost of the demand change.

The failure to assess the impact of changes is the root cause of the flood of demand changes. Changes come at a cost. The cost of changes should be evaluated and the customer should be informed of the consequences of the changes. If the customer does not know the cost of the change, it will be hard for developers to understand.

Compared with demand developers, customers may have insufficient understanding of demand changes and think they have to pay for them, so the software development team must serve them. Therefore, customers tend to be reluctant to change their needs. demand changes are regarded as child games, and they can change their needs as they like. Therefore, we should clarify our attitude when we contact our customers, especially to make them aware of the costs and risks arising from random changes. If the customer thinks the cost is too high, the developer does not need to modify it in time and follow the original progress. However, the change must be recorded and the next version is being modified.

 

How can we effectively control changes to non-functional requirements?

Before making ANY changes, we must consider the consequences. Because of the important position of non-functional demand changes in development, once the demand changes, the impact is very wide. Therefore, effective control of frequent changes to non-functional requirements is not negligible.

 

(1) Establish a clear non-functional demand baseline

For software development, changes are inevitable and unavoidable and can only be actively addressed. Therefore, it is important to establish a clear non-functional requirement baseline during development. If the non-functional requirements are not met, the baseline scope will be vague, and customers will easily seize the loopholes. Many unnecessary changes will often be required. If the non-functional requirement baseline is well performed, the document is clear and signed by the customer, the non-functional requirement changes proposed by the customer will be greatly reduced in the future. Therefore, when establishing a demand baseline, you must never be soft. This is not intended for the customer, but not to let the customer develop the habit of frequent changes. Otherwise, there will be endless troubles.

 

(2) establish a demand change management process

Demand changes have an important impact on the success or failure of software development. Therefore, it is necessary to control demand changes, neither to reject the customer's change requirements nor to accommodate the customer. In other words, the purpose of demand change management is not to control the occurrence of changes, but to manage changes to ensure orderly changes. The demand change management process includes the change application process, the approver, the approval items, and the approval process.

There are two purposes: first, standardize the customer's change process as much as possible, and reduce unnecessary, non-urgent, non-reasonable, and invalid changes with the intention of non-senior leaders. The second is to leave a written basis to prepare change accounts for possible future cost accounting. Therefore, any change that fails to perform the approval process is invalid and will not be accepted. In practice, people often do not want to implement formal demand management processes for small demand changes. They believe that this reduces development efficiency and wastes time. However, this idea will gradually make demand changes uncontrollable, and ultimately lead to project failure.

 

(3) confirm whether the customer accepts the price of the change

Demand changes, as an unplanned risk, must have an impact on the project, but only the size difference. In addition, the customer's needs will never be met. One day may be the same, in order to control frequent demand changes. The cost generated after the change needs to be evaluated and quantified, and an analysis report should be submitted to the leaders of both parties. Otherwise, a blind compromise will only make the project worse. Therefore, it is necessary to make the customer realize that changes are costly and do not make the customer suffer from random changes. In general, if the customer thinks that this non-functional change is necessary, rather than being put forward by their superiors, they will accept these costs. Through communication and negotiation with the customer, the development team will not blame the customer even if there is no return.

 

(4) strengthen contract binding force

Although it is difficult for a software development contract to precisely define each requirement at the beginning of signing, contract alone cannot help, but the binding force of the contract cannot be ignored. Sometimes, in order to enable the customer to sign the contract quickly, the sales staff often rashly decide and unilaterally agree to the customer's requirements. When the customer puts forward new requirements, the sales staff often looks at "should" as a small change, which has no significant impact and may directly promise to be able to change. Therefore, when you sign a development contract with the customer, you can add some relevant terms, such as specifying the time for the customer to propose a change request, and specifying the conditions for the change to be accepted, rejected, or partially accepted, you can also specify that the change control process must be implemented when a demand change occurs.

 

(5) strengthen emotional communication and pay attention to communication skills

Most of the time, contract binding alone will not solve the dispute. When the customer is in a hurry, there are many companies that want to do it. For example, sometimes it is an unreasonable requirement, but the customer will argue why they will not do it. This is a job within the scope of the contract. Therefore, simply viewing the contract is useless.

What should we do? The common practice is to win the customer's sympathy through emotional contact. What we often say to our customers is that we should make reasonable demands. This sentence has a unique significance in change management. In our line of saying: doing a good job in demand change management control is only half done, and half of the work is to make sense, to persuade customers to turn back with their hearts and feelings.

 

The moon is overcast and clear, and the tide rises and falls. Changes do not always cause us trouble and sometimes surprise us. In software development, we need to treat the non-functional demand changes proposed by the customer with a normal mind. We do not reject them or accept them blindly.