Software engineering principles and practices

Software Engineering

Requirements Are Volatile: Design, Resource Allocation, and Lifecyles Aren't So Flexible

For the majority of software development initiatives, bad requirements are a fact of life. Even when there is a high quality elicitation process, requirement change throughout the software lifecycle model. This is expected, if not desired to build a system that the customers wants and will use. But, it's difficult to change design and resource allocation once these have been developed based on initial requirements. And, the lifecycle model itself makes adjusting processes to accommodate new requirements difficult, even when abandoning discrete models in favor of more continuous approaches.

Bad requirements happen for many reasons. But, of all the requirements engineering processes, requirements elicitation has the highest incidence of malpractice.

Too little time is spent on elicitation and it is difficult to get customers to communicate their requirements because they either do not know what they want, are unable to fully define what they want or are unable to decide what they want. There also exists a communications barrier between systems developers and domain experts that provide the requirements. System developers do not know the terms of the domain and most domain experts are not conversant in software engineering terminology. Also, developers and customers often have different meanings for what a "requirement" is. Customers consider a requirement to be a statement of need while the developer sees a requirement as the real need of the customer that can be tested and validated. Despite the hype, formal methods have not been effective in bridging the gap between the customer and the developer.

The requirements analysis process is intended to verify the consistency and feasibility of requirements. However, technology issues often arise because of over or under analysis. Over analysis fails to set priorities for what is important and attempt to take on too broad of a scope while under analysis often takes place as a cost savings measure. Tools to support analysis have high learning curves and become shelf ware if they impose a process that is conflict with an organization's process.

Requirements management is also another source of questionable requirements.

Requirements management is meant to control change during and after the development of requirements. However, it is difficult for projects to strike the appropriate balance for the acceptable level of change. According to research sponsored by the Computer Resources Support Improvement Program (CRSIP):

The accepted requirements volatility metric is 1% of requirements per month. If it is much less, one should ask oneself if the system will be desirable to its intended audience. If it is much more than 2% a month, development chaos is all but assured."

Because requirements are volatile, projects need to use a system that facilitates the definition of a requirements baseline and an incremental lifecycle that supports changing requirements.

Requirements validation and verification needs to confirm existing requirements as well as identify missing requirements. However, customers cannot always understand mechanisms used to validate a system, introducing a quality issue. Often, validation and verification is performed too late in the requirements engineering process, rather than being a part of the initial elicitation, stage.

Bad requirements lead to poor software design because they provide deficient input into the development of the design and they lead to incorrect resource allocation decisions that cannot be easily corrected. The following Capers Jones's quote in Design Methods: Seeds of Human Futures appropriately sums up the situation of what happens when the wrong requirements are used in software design:

The fundamental problem is that designers are obliged to use current information to predict a future state that will not come about unless their predictions are correct. The final outcome of designing has to be assumed before the means to achieving it can be explored: the designers have to work backwards in time from an assumed effect upon the world to the beginning of a chain of events that will bring the effect about."

The data, architectural, interface and procedural designs are all negatively influenced by inadequate requirements. During the design phase, decisions are made regarding the appropriate hardware, programming languages, staffing, end-user interfaces, etc. When requirements are ill defined, resource estimates are likely to be incorrect.

Fixing misestimates of these is easier said than done one the project is underway. The Mythical Man-Month by Frederick Brooks is a book that explains why it's difficult to add new staffing resources to help a project catch up because the performance of programming teams does not scale linearly.

To make matters more foreboding, he asserts that by adding programmers to a late project, the product is likely to be even later because efforts devoted to communication and administration becomes larger.

And, it may be difficult to reset budgets to obtain additional resources once a project is underway.

Projects can't necessarily count on the use of new software productivity/quality tools and techniques to bail them out either. In "The Realities of Software Technology Payoffs," Robert Glass discovered that the benefits of Structured Techniques, Fourth Generation Languages, Computer Aided Software Engineering, Formal Methods, Cleanroom Methodology, Process Models and Object-Orientation simply do not match their claims. Glass estimated that productivity and quality benefits of these approaches can realistically expect to range widely from five percent to seven percent, but more studies are needed. Glass also warned that there is a substantial learning curve for these tools and techniques that initially leads to lower productivity, then to slow improvement over time.

As was the case with the software design process, bad requirements have negative implications to the entire software development cycle. Lifecycles do not easily accommodate volatility when requirements need to be changed. The Waterfall lifecycle model is one of the most commonly used lifecycle models for software development. It emphasizes that software is developed in sequential phases (requirements, analysis, design, implementation, testing, and operations and maintenance) with established milestones and reviews at the end of each phase. The entire scope of the project must be addressed at each phase and a phase must be completed before another can begin. Under this model, projects face extreme risk if requirements are not properly defined. Although it allows a revisit to a previous phase, it requires the definition of a huge bulk of requirements to continue though the lifecycle, leaving a project more vulnerable to inaccurate and incomplete requirements.

Recognizing the inherent risks in the waterfall model, Barry Boehm created a new lifecycle model, the Spiral model, based on the Waterfall model.

The Spiral model recommends that developers should only define and implement the highest priority features. Then, the team should obtain feedback from users and customers and continue to incrementally implement additional features in small chunks. Each cycle in the Spiral model includes identification of objectives, alternatives, and constraints for each alternative.

Alternatives are to be evaluated relative to objectives and constraints with the identification of any sources of project risk. If risks are present, they must be mitigated by methods such as prototypes, simulations and benchmarking.

However, Boehm's Spiral model may actually introduce additional risk, especially in the development and implementation of complex systems. It's often difficult to select the appropriate design method without an understanding of the complete data model and it may difficult to produce a design that will accommodate the future when all the requirements are not considered. It may also prove to be problematic in forecasting resources for projects that have predetermined schedules in the absence of a full set of requirements.