No Requirements — No Problems

After 15+ years of work in software development, I collected quite a lot of ineffective, pointless, terrible, stupid, awful, and dangerous practices of managing application requirements. So, here is my personal Top 5 of the worst practices you should avoid at all costs.

I am going to skip apparent issues like a lack of information or conflict between the different requirements. Instead, I am going to concentrate on less obvious but still crucial flaws in requirement management.

Missing Solution

This is a widespread mistake of inexperienced teams (e.g., startups) — build a tool instead of a solution. The team is concentrated on building a perfect tool, while it is not clear who, why, and where will need it. And such a tool ends its life in the same place where all useless tools are — in the dump.

Every time a customer, product owner, or system architect writes a requirement, he has to ask himself why it is needed and if it needed at all. It may appear that the use case that requires it is very uncommon, and there are existing tools that may cover such exceptional situations. Instead, it is better to concentrate on understanding the business processes (workflows) and related issues and find a solution that can simplify these processes and solve the issues.

Wrong Target Audience

Every application (integration, tool) has to have its target audience — a group of people interested in the solution. These are people who should adore this solution as it completely satisfies their needs in some areas. Another standard requirement mistake is in targeting the wrong group of people or targeting everybody.

It is essential to understand how the application can help other people (see the previous chapter) and understand who should use it. Knowing this audience, the team has to predict the needs of this group. Marketing research may help a lot here. And finally, when these needs are clear, it is time to cover them with the requirements.

Targeting everybody is a bad idea because people are different in multiple aspects, and it is troublesome to find some common need that exists and not satisfied yet. If you manage to do that, then you are a genius!

Fragile Requirements

When somebody is writing requirements, this person usually thinks about the new features he/she adds, or existing features that should be improved. It is the right approach as it guarantees continuous progress. However, people often forgot that requirements have to be flexible enough to adapt to the environment changes. New technology, new audience, new needs — these things may change and change often.

The mistake here is to think about the requirements as about monolith and unchangeable entity and write them in the correspondent way. Such requirements can become fragile very quickly, and then the author has to either rewrite them from scratch or throw them out. The best practice here is to write the requirements that describe the concept, not the implementation.

No Common Storage

Many people work on the same project, and they want requirements to be properly organized in one place. Usually, this is some king of wiki, ticketing system, or similar storage. However, there are situations when requirements split between the many places, and it is very hard (sometimes even impossible) to get all the information you need. You should have access to all these systems, know the structure (which can be different as well) and be able to collect the requirements in one place. Such an approach is extremely inconvenient and very hard to use.

An even worse situation may happen when requirements are not stored at all. As a consequence, if some team member leaves the team and does not describe all the features he is aware of, then this knowledge can be lost forever. Other team members must spend much time to recover this information to continue work on a project.

Developer Defines Expectations

Another common mistake is to ask a developer to define expectations or requirements. It may sound reasonable as a developer is a person who knows best how the application works. However, on the second thought, this idea is not that good.

A person who writes code knows only one thing for sure — how this code works, what input data it expects, and what results it produces. A developer may know the existing domain model, but this model may not cover business processes as a customer see it. This person is concentrated on the things that already exist, while requirements must define concepts for nonexistent entities. A developer may provide valuable recommendations about the complexity of tasks or possible technical issues, which is essential information for a project. A person who writes requirements should consult with a developer, but a developer must not be the person who writes requirements and defines the expectation in the first place.

I hope these worst practices can help you to avoid such situations in the future, and save you lots of time and effort. Let the knowledge and experience be with you!