Requirements volatility (RV) refers to additions, deletions, and requirements modifications during the system’s development life cycle. Requirements volatility is defined as the tendency of requirements to change over time. Requirements are added, deleted, and modified throughout the software development life cycle. Despite being seen as a natural characteristic of software projects, improper management of requirement changes can adversely affect project cost, schedule, and resulting product quality. Therefore, uncertain requirements are a primary factor contributing to project failures. Multiple terms, including requirements change, uncertainty, instability and volatility, are commonly associated with or related to the same phenomenon.
The nature of change is an integral characteristic of requirements. Therefore, requirements management is a process of managing changes in requirements. While requirements changes can occur due to the natural evolution of user needs over time, the actions of stakeholders at the various stages of the requirement engineering process, including elicitation, analysis, validation, and management, can also contribute to requirement volatility. Changes in market conditions, technology and regulations are some of the situations that can lead to volatile requirements. Most of the time, software teams have no control over them.
Requirements volatility creates rework in design and code that increases system development cost and time and compromises system quality. Ignoring requests for requirement changes can cause system failure due to user rejection, and failure to manage RV can increase development time and cost. Requirements volatility increases development cost and time, and, thus, its implementation needs to be managed carefully. Implementing requirement changes incorrectly may lead to more volatility and higher costs. Therefore, a robust change management system is essential to identify the impact of a requirement change on cost and schedule as well as on other requirements and system objectives. Changes that have a big impact need to be approved by a committee of senior managers from the user departments and the project sponsor. Current change management methods focus largely on design and code artefacts and very little on requirements. However, with a comprehensive change management system in place, requirement changes can be controlled. This provides a sense of security and control over the process.
Requirements volatility due to inadequate user representation of various functions can be minimized by having the right number of users to represent each function. Having a stable team of developers and users on the development team will ensure continuity and avoid requirement changes that come with changing team members. Structured definition methods are useful when documenting and managing requirements. These methods can also help to update volatile requirements correctly and completely to avoid further volatility. Moreover, verification and validation of requirements using inspections, reviews and walk-through exercises play a crucial role in ensuring requirements are correct, consistent and complete, and they can help to avoid changes to requirements during later stages, instilling confidence in the process.
Software architecture that guides the software product’s overall vision is one area significantly affected by requirements volatility. Software architecture plays a prominent role in software development and is the foundation of software systems that shape the outcome. Making sub-optimal architecture decisions can decrease system quality and cause problems later on. Since critical architecture decisions are primarily made based on the requirements at hand, changes in requirements may necessitate the redesign of the software to accommodate those changes and may lead to an unstable software system. Architecture decision-making has become a collaborative team task rather than a single architect’s duty. Therefore, all team members must know the possible requirements for changes. Correcting shortcomings in a system at the end of its development is very complicated and far more costly than identifying and addressing them during initial design.
Quality attributes, or non-functional requirements, constitute the majority of stakeholder concerns and greatly influence architecture shaping. The interactions between quality attributes are among the main factors to be considered during architecture design, as architecture either allows or precludes almost all system quality attributes. Software architecture design decisions are primarily based on architecturally significant requirements critical to shaping the system architecture. While quality attributes take a large share of architecturally substantial requirements due to their ability to affect the whole software system, they can also include functional requirements.
With the widespread adoption of agile software development, the perspective on requirement changes has radically transformed. Agile principles embrace changing requirements even in the late stages of software development and encourage leveraging change for customer competitive advantage. However, these principles also advise awareness of the potential consequences of requirement changes. While software architecture design is primarily the responsibility of the software architect, the active involvement of other stakeholders, such as software developers, product managers, and customers, is crucial. This is for a comprehensive understanding of the criteria the architecture must meet. A vital element of the architecture design process is recording architecture design rationale, as understanding the reasons behind a particular architecture design decision can be critical during software system maintenance and evolution. Architectural technical debt refers to the consequences faced late in software development due to sub-optimal architecture decisions and trade-offs.
Software teams accumulate architectural and technical debt due to their actions and external events related to natural software ageing and evolution. Even though technical debt related to coding issues can be detected using various tools, architecture technical debt remains invisible and grows over time. Factors contributing to accumulating architectural debt include uncertainty about requirements at the beginning of development. They also include evolving requirements during software development, time pressure, feature-oriented prioritization and specification issues with critical architectural requirements.
Software development is dynamic, and fixed requirements cannot be expected. The issue is not with changing requirements; the problem is with the inability to predict volatility and the need for adequate approaches for dealing with requirements volatility. The negative impact of volatility can be minimized if identified at its earliest. It is more important to determine its causes at early stages. Once causes are detected, volatility can be eradicated and may not go forward in the further phases. Providing complete, consistent, stable, unambiguous, and correct documents throughout the life cycle improves the chances for a higher-quality software system. Requirements volatility must be considered as a part of project risk assessments.
It is imperative to identify the factors that cause requirements volatility, the possible impacts and the relationships between them. Even though requirement changes were frowned upon during the pre-agile era, today’s realities of software development demand using them as an opportunity to improve the software product. It is not true that all requirements changes bring equal value to the software product. While inevitable situations such as addressing evolving user needs or adapting dynamic market conditions justify changes, it should be attempted to minimize unnecessary changes due to process, practice or organizational issues.
The product owner is the link between the software team and product management. In a company, “Product Management” refers to the team that determines the high-level requirements for products and makes decisions about product roadmaps. The product owner is responsible for communicating with product management to identify product requirements and then converting them into user stories with the software team and monitoring their progress. For most interviewees, the product owner is the sole point of connection to the requirements elicitation and analysis phases. During the clarification process, software architects are occasionally consulted to define the technical feasibility of requirements and choose the most suitable implementation solution. At this phase, requirements volatility factors include changing customer needs and evolving technological understanding.
The most common reason for requirements ambiguity is inadequate or missing backlog item descriptions. Features or backlog items lack detailed information; for example, a backlog item may have only a name, but no one knows why it is there. The tool includes a customer acceptance criteria field in the requirement description. Most of the time, something is recorded in this field. However, the description is often a couple of lines of text at an abstract level. As most private customer product requirements are decided within the company, corporate customers are the main source of requirements changes. The long-term business relationship between corporate customers and the company makes it difficult to refuse to adapt to changing customer needs.
The severe market situation requires constant changes in requirement priorities. However, delivering a solution sometimes requires collaboration between teams from various business units. For example, a team that has developed a mobile application might have to interact with teams that have developed the same application for various platforms and with teams that provide server-side support. In this situation, changes in requirements in one unit lead to changes in the other. In some cases, information originating from the customer has to flow through several different external and internal units before reaching the development teams. The information is subject to distortion in each of the handovers, and the broader the distance between the customer and the development team, the higher the level of possible distortion. Communication issues may begin during the elicitation and negotiation phases with the customer. Typically, this is because the terminology and semantics vary between customers and developers. These differing domains bring different terminology and concepts. Later in the process, software teams may face language barriers and cultural differences that pose communication challenges.
Changes within the software team and other stakeholders actively involved in the software development process contribute to requirement volatility. Many software teams state that requirements descriptions are ambiguous and poorly documented. Constant personnel change leads to knowledge loss. Defining requirements is an early phase of the software development life cycle. Requirements are the foundation of the software development. They provide the basis for cost estimation and project schedules as well as for designing and testing specifications. The success of a software project, both functionally and financially, is directly related to the quality of its requirements. Constant changes to requirements during the development life cycle significantly contribute to the quality of requirements specification.
The level of detail in requirements information varies depending on the product and the team. Sometimes, only a feature name is recorded, but at the other extreme, descriptions include even the contact information of the relevant technical specialist on the customer side. In the case of private customer products, requirements are created by experts based on a foreseen market. Usually, the creator of a requirement is recorded, but sometimes, it is not known whether the requirement originated from a customer or an internally identified technology gap.
Software architects are not directly involved in customer requirement elicitation and analysis. In the case of a company, elicitation is accomplished using techniques such as focus groups, beta testers, and direct customer communication. Occasionally, customers’ ideas are expressed so highly that they are difficult to translate into requirements. On the other hand, requirements may be stated as full-scale technical specifications. Customer needs are clarified during the requirement analysis.
The causes of requirements volatility cannot be overcome fully, but we described some causes like (poor communication between stakeholders and developers, technical aspects and bad management process, etc.)
Requirements volatility has an impact on the whole software life cycle development. It has impact on the project schedule, cost, and quality. It cannot be avoided, but we can manage it to reduce the effect of requirements volatility by following some analysis, design, and coding methods. Due to the impact of requirements volatility, many projects have failed.
