Why are software requirements allowed to change if it means more work for software engineers? [closed]

Question

In many projects, software requirements change, sometimes meaning we software engineers have to throw out our work and start over. Heck, we have entire methodologies built around the assumption that requirements will change.

So, why are requirements changes allowed to happen in cases where the software engineers then have to put in more work to fulfill them?

Answer 1

Because software engineering isn’t done for some abstract pursuit of software engineering, it’s about building a useful result.

If halfway through the construction of device A you find out that it won’t be useful, won’t be competitive, has huge unforeseen issues, etc., then you’re better off scrapping it and building device B. The dev effort sunk into A is sunk cost. Any assessment of what’s worth doing needs to be informed by today’s trade offs, not sunk cost that’s done and over with. While it’s always difficult to scrap your own work, it’s just part of building something ultimately useful.

Answer 2

why are requirements changes allowed to happen

They aren't "allowed" to happen. They happen.

There is simply a non-zero amount of time between the point in time where the requirements are defined and when the software is delivered. Within this non-zero amount of time, the universe has changed.

Even the process of gathering the requirements itself takes a non-zero amount of time, so the state of the universe at the point when you started writing down the requirements is different from when you finished writing them.

Maybe examples will help.

One example that was recently in the news is the guidance and navigation system of the OSIRIS-REx lander that landed on asteroid Bennu and took a sample of the asteroid.

Scientists studied the asteroid Bennu as best as they could, given that Bennu is only less than 500m wide, and even at its nearest point to Earth, it is still almost half a billion kilometers away. Based on all their measurements, their best models, and experiences with other asteroids, they came to the conclusion that Bennu had a smooth, even, sandy surface. So, they designed a guidance and navigation system for the touchdown and sampling part of the mission that was based around a LIDAR altimeter.

So, the requirements they came up with were, among other things: the guidance software needs to be able to autonomously course-correct the landing with an accuracy of 25m and use the LIDAR altimeter to do so. And that's what the contractor implemented.

Except, when the spacecraft arrived at Bennu and sent home the first photos, much to everyone's surprise, it showed an uneven, rocky terrain with sharp edges, cliffs, crevasses. And there was no single 25m wide landing spot to be found.

If they were going with your solution, they would have said "well, the requirements are what they are", the spacecraft would have crashed, destroying 1 billion dollars of taxpayer money, 20 years of work, and shattering the hopes and dreams of dozens of students working on the project, let alone the careers of scientists who depended on publishing the results of the mission.

But what they did instead was to adapt the guidance and navigation system to optical terrain navigation using the cameras that were never designed as real-time navigation cameras, and improve the accuracy to less than 5m. The mission was a resounding success, and in 2023, the spacecraft will return between 400g and 1kg of material back to Earth. (The minimum required for mission success was about 60g.)

Another example is a project I heard about recently, which actually did have a contract exactly like the ones you are envisioning. There was a fixed set of requirements that were never allowed to change, a fixed set of features that were never allowed to change, a fixed price that was never allowed to change, and a fixed delivery date that was never allowed to change. As you might have guessed, this was a government project. The timescale was about 3 years.

After about 1 year of development, there was a change in the government, and the laws changed. This meant that the software was completely useless. From this point on, the developers were forced to spend two years of their life developing a piece of software that was completely useless. This was incredibly frustrating, and as a result, the company lost several of their best developers who either left frustrated or simply burnt out and got sick.

After about 2 years, there was an organizational reform, and the department that this software was written for, didn't even exist anymore.

It also became clear that the company was not going to make the deadline, because of the developers that had left or became sick, because the remaining developers were frustrated and unmotivated, and because of some unforeseen complexities in the implementation. As a result, they had to hire additional developers for a project that would never see the light of day, and the project turned into a death march to hit a deadline that was completely meaningless.

They also weren't able to bid for the contract to develop the replacement software, even though they were in the perfect position to do so, since they already had acquired a certain amount of domain knowledge. They simply didn't have the developer capacity to support two such large projects at the same time.

So, in the end, everybody lost: the government, because they had to pay for a software they were never going to use. The company because they not only lost some of their best developers, they also actually lost money on the project due to the last minute hires they had to do. The developers because even in the best case, they were completely demotivated and frustrated, and in the worst case, actually got sick because of that. And the taxpayers who indirectly paid both for the software and the medical bills.

In neither of these two examples did someone "allow" the requirements to change. The requirements just changed.

Answer 3

What do you mean allowed?

Do you think that businesses like inefficiency, or throwing things away? Change is one of the true constants in the world - as is human inability to predict the future.

One tiny consequence of that fact is that engineers sometimes need to throw stuff away.

Answer 4

There are three reasons for requirements to change:

1. Documented requirements were incomplete, wrong or inaccurate;
2. The world continues to change independently of any projects that might be affected;
3. Knowledge acquisition during the project when software engineers and users learn from each other what’s really needed and what’s possible.

Change of requirements will therefore happen, whether they are allowed or not. Three consequences:

• ignoring them would lead to bad quality, (i.e. a according to ISO, when a system does not meet the real expectations of the customer);
• accepting them has influence on the project efforts and costs. How much depend on how the project is organized. The question of who will have to support the work and cost consequences is a matter of contractual relationship and general management, beyond the scope of software engineering;
• early identification of changes significantly reduce their cost.

Traditional methods cope with this reality by addressing the cost issue with some kind of change request procedure.

Agile methods emerged to better cope with the reality of requirements and their change:

• requirements are identified just in time when they are needed and explained in detail when sufficiently understood: this reduces the probability of unnecessary changes;
• changes are welcome, which allows to take them into account as early as possible: there is no additional cost, since it is fully included in the development strategy.