Requirements – how they affect a developer’s work

Gathering requirements from the client (or a representative, but let me call this person client for sake of simplicity) is as important in software development as it is in other fields of business. But the way that they are documented and changes in them play a significant role in the software developers’ productivity and thus, the delivery of the product.

Documenting requirements

Nowadays, the most popular way of documenting the requirements are user stories – “cards” containing a closed set of things that need to be displayed / usable in system. I won’t be diving into what exactly should a user story contain, nor what tracking system is best. What I want to address, is the specificity of the user stories.

If the user stories are not very specific (that could mean as well detailed, but not being vague is more important), two people reading it may intrepret the desired result differently. If one of the persons is the client and another one a software developer, which will be implementing it, this can lead to either of two things:

1. The developer goes with his “gut feeling” and just implements what he thinks should be done to satisfy  user story’s acceptance criteria.
2. The developer recognizes, that the description is ambiguous and contacts the person who created it to clarify things.

Now, what happens next in both cases? In the first one, after the feature gets implemented, it may be what the client wants and that’s great. But it also could be something that the client does NOT want. This is a spot for a potential argument of the parties.

In the second case, the sole implementing process could be deferred, as clarification may take some time, depending on who is setting the criteria for acceptance. But that avoids a potential waste of work and unneeded argument. This outcome is better.

Now, why requirements become ambiugous? Because of a defective implementation of process of documenting them. This often can be the case with new clients, who haven’t done such a thing before and don’t know what information is important for the development team. But that is not a bad thing, we all have something to learn and can’t expect everyone to be a specialist in everything. Other case is that the client is not specific on purpose, but that’s just a bad will.

Requirements changes

I can’t tell if requirement changes in software development are more frequent than in other fields, building construction for example. But there is an important difference how requirement changes are perceived by the client.

Let’s say a person wants to build a house (let’s take into consideration a house made from concrete). She wants to have a salon, a kitchen, two bathrooms and a garage. She goes to an architect, who creates a design and after that the building crew starts the job. After the foundation is in place and first bricks are being placed, the woman changes her vision and wants swap places salon and the kitchen. That’s probaly doable, since no installations weren’t laid down. The plan gets changed and the work continues.

But what if she wanted to make the swap, when all the walls were placed and electricity and plumbing was already in place? It would be either very costly or down right impossible – the crew haven’t laid down the water pipes in salon vicinity, because there was no need for, they were near the kitchen and the bathroom.

Things like this can happen in software development too. But, since there is no physical structures to show, what needs to replaced / removed / rebuilt, it is a more challenging task to justify the cost for a layman than in the case of house building. Everybody can easily understand, that crushing down a wall or putting new plumbing takes much effort and could be costly. But in the IT, there’s no easy way of visualizing such things.

Conclusion

Requirements are different for every project, but every project suffers the same consequences if they are poorly defined or change frequently – development slows down. Issue requires empathy on both sides to be solved: the client needs to know, that his change of my mind may be very costly and the developers need to communicate, what details are important for their work.