Why bother gathering requirements when we know they will change?

Question

I have always been taught that one of the most important things to do at the beginning of the developments of a software is the Requirement gathering. I have also been taught that requirements always (most of the time) change dramatically between the beginning and the end of the project, either because the client wasn't really sure what (s)he wanted, or because (s)he changed his mind about some functionalities, or for any other reason.

So I have a question:

Why do we spend so much time gathering detailed requirements at the beginning if we know that they will be invalidated and change in the not so distant future?

Answer 1

Because not all requirements do change, and not all requirements change in the same ways. You're not going to spend awhile working on software to manage a warehouse, only to suddenly decide to instead re-work the software to schedule dentist appointments.

Some requirements do change that have a big impact, like changing what OS it runs on, and sometimes requirements change to just reword the label by a text box. However, the rewording of a text label is far more likely, the OS is not. So there is value in getting many aspects of the software thought out and written down.

As you build lots of software for a variety of different people and domains, you'll start to get a feel for what's up in the air and what isn't, and you'll likewise get a feel for how to design software to be flexible in the right places.

Answer 2

Why do we spend so much time gathering detailed requirements at the beginning if we know that they will be invalidated and change in the not so distant future?

It's time to stop gathering requirements the moment writing and demonstrating code becomes the most effective way to communicate your understanding of the requirements. If you continue gathering beyond this point you're slowing things down. However, if you don't gather requirements up to this point you are also slowing things down.

If you're doing it right, requirements change both while you're gathering and demonstrating. Why? Because the change is the result of effective communication.

You should be learning (so should your product owner). Which means the point in the project when you're the dumbest is at the start. So you don't want the start set in stone. Stop gathering requirements when it stops causing meaningful change.

It's a bit like microwaving popcorn. Stop when too much time passes between the pops.

Answer 3

One facet of this; If you have no requirements why are you writing any code at all? Code doesn't exist to please itself. Whatever reason you're writing for has a requirement hidden in it, and the sooner you understand what's actually important, then you can make decisions that set you up for success.

You need to know what "done" looks like, otherwise you're just flailing randomly and hoping to write useful software by accident.

Answer 4

What you're probably thinking of is Big Design Up Front, and yeah, it's not necessarily the best way to manage a software project.

But you still need a clear picture of what you want to accomplish when you undertake a new software development project. Broadly, you need to know what benefits you expect from the new software, how much money it will save, and the features (in broad brush strokes) it will have. More specifically, you need to know, in detail, what the business processes look like, and how those business processes are going to be embodied in the new software.

The problem is, you need detailed instructions before you can begin coding. Otherwise, how are you going to know what to do? These instructions don't necessarily need to be formal (it can be in the form of rough sketches) or highly detailed, but there are certain ingredients that you know you're going to need. You need a database design. You need a UI design. You need methods that implement business processes. And so on. The only way you're going to get these is by turning features into requirements, and you do that by having meetings with stakeholders, understanding their business processes, showing them mockups, creating high-speed functional prototypes, and so on.

Agile software development processes see requirements, not as an ending point, but as a starting point. Requirements are allowed to evolve, if it becomes clear that they are inadequate in some way. Regardless, you need to have instructions that are detailed enough to write code from, and "bake me a cake" isn't specific enough.

Answer 5

I have always been taught that one of the most important things to do at the beginning of the developments of a software is the Requirement gathering.

Well, in more than three decades of software development I have made the first hand experience that detailed requirement analysis (if you mean that by "gathering") is only really important for developing the next feature or feature slice of a software, and these features should not be too big (that's why you should try to cut big features down into slices). And over these years, this experience has also reached the mainstream and has become part of the so-called "agile" methodologies. So whoever taught you this, it seems they told you some outdated academic stuff from the past.

So the answer to

Why do we spend so much time gathering detailed requirements at the beginning

is - "we" don't, only theoreticians from the past do, who have no own experience in effective software development, and most probably don't know what agile development means.

Of course, there are sometimes sensible reasons why a lot of time should be invested into requirement gathering at the beginning of a project:

• because you need to make a fixed-price offer to a potential client. When calculating the price, you don't want to overlook a requirement somewhere hidden in one half-sentence of page 42 of the customers wishlist which takes several additional months or years to develop.

• or, if you are the client, you want to make sure a potential contractor will develop all the features you expect from him for a certain amount of money, so you make a detailed requirement list for the contract.

• because you need to make some architectural decisions about the system beforehand, and you don't want to overlook a requirement which collides directly with the chosen architecture

None of these reasons, however, expect requirements not to change over time, or each and every feature of the software to be analyzed in every gory detail before you start writing the first line of code. For example, if you make a contract with requirement 1 2 and 3, and requirement 3 is replaced by requirement 4, then this is a good basis to re-negotiate the contract. Or take architectural decisions, these are typically founded on some general notion about the non-functional requirements, those don't become inherently wrong because functional requirements change, and they don't become wrong if the non-functional requirements change within some reasonable degree.

Another point I would like to mention that "gathering requirements" does not necessarily mean an analysis in detail. It is always a good idea to constantly collect ideas for new features and improvements in some backlog or issue tracker throughout the whole project, not exclusively at the beginning of a project, but parallel to the development activities, whenever one comes up with a good idea which could improve the product. This is indeed an important part of requirements management, since it will allow you later to make a decision which of these ideas should be priorititzed, which are beneficial enough to be analysed in detail and implemented as new features.

Answer 6

Why do we spend so much time gathering detailed requirements...?

Requirements form the contract between the development team and the client. If you don't gather requirements, nobody will really know what is to be built, and there will be no hope of success.

...at the beginning if we know that they will be invalidated and change in the not so distant future?

The time at which requirements are gathered depend on the process used. Waterfall process dictates that requirements are gathered at the beginning of the project and must not change. A change in requirements in the waterfall process is a huge issue and may lead to re-architecture, re-design, re-implementation, re-test depending how far into the process you are when requirements change. This is why if you use waterfall process, a lot of time is invested in getting the requirements right, often a software requirements specification (SRS) document is created and approved by the client.

Since change in requirements with waterfall are very expensive, and requirements often change, there are better processes for managing changing requirements. Agile is a very popular process methodology where requirements (often expressed as user stories) are prioritized, and enough requirements to fill a 2-4 week development effort are chosen and implemented in a sprint. During the sprint requirements must not change, but once the sprint is over, the customer may review the product and decide to change, add, or remove requirements for the next sprint. The cycle repeats until the customer decides there are no more requirements.

There are many process models that do requirements gathering differently, and the process used should be chosen based on the project.

I have also been taught that requirements always (most of the time) change dramatically between the beginning and the end of the project

Requirements may change, but there should be procedures in place (determined by the process used) to limit/control change in requirements.

Answer 7

If it is a complex system, it is difficult to know which requirements you actually do have. If you start with stating the requirements you believe you have, you can later take a step backward and look at the big picture, and suddenly realise what you really requires.

Answer 8

Many people don’t know what they want. They cannot clearly express their requirements. Therefore, as a software developer, you gather the requirements as good as you can, show them the requirements, and they will find it much easier to find how your requirements don’t match what they actually need. So you first need the requirements to have a. Chance to get the real requirements.