By: Ulf Eriksson

Working with requirements is a serious responsibility. The people behind them are those that provide the rest of the team with something to develop and something to test.

After the initial briefing and discussion about a new project, they effectively kick-start the process that will eventually result in a finished product.

In this article, I take a look at the five worst mistakes that people commit when working with requirements and suggest methods how you can avoid and overcome them.

1 – Working without a strategy

When heading off into the minefield of requirements writing, make sure you have a strategy that points you in the right direction.

Very much like a compass, working with a carefully thought-out requirements strategy ensures that your efforts are in alignment with the requirements team’s overall bearings and not a solo gig.

Alas, too many requirements writers are tempted by the latter.

Working without a requirements strategy can lead to a bewildering range of quality levels in finished output by the various members on board the requirements team. Some may be too long, others too short, yet others will have too much details for their level.

Having a requirements strategy saves you a lot of hassle because it provides clear guidelines on how the work should be done. A solid strategy should cover the three main areas of requirements: management, development, and monitoring and documentation.

The guidelines contained within the requirements strategy are only intended for a general understanding of the situation. When it comes to adapting it to a particular project, then you’ll to devise a research plan.

2 – Working without a plan

If the requirements strategy points you to the forest, then the requirements plan shows you how to cut down a specific tree.

And don’t worry, you won’t have to be a Napoleon to produce a brilliant requirements plan.

What you need to do is to follow the principles laid down by your team’s strategy and interpret them in the light of the facts about the project at hand. Add in your individual skills and flair, and you’ll have a solid plan in no time.

When people work without a plan, the end-result is often a lengthy requirements gathering process which will still result in some missing requirements.

They also tend to fail to see an inherent order in the requirements they will be working and simply list them haphazardly; this will negatively affect the development phase of the project.

3 – Working without the right tools

No matter his or her level of skill, a craftsman will always be limited by the quality of the tools used.

The same applies for requirements writers. In an era where techniques like Agile and Scrum form the backbone of the workflow in a software development team and automation is implemented wherever possible, having the right tool is imperative.

One of the simplest and most important tools is a first-class requirements template. If you are still doing it old-school on a Word document, then you might want to check out a tool like ReQtest which will make creating and filling in requirement template forms a cinch.

Teams that do not use templates will end up with multiple styles of requirements writing on their hands which can be difficult and time-consuming to interpret. There is also the risk of important information being omitted which can subsequently cause major problems downstream in the development process.

Any template should have clearly marked sub-headings which cover all the basic information that details the requirement in question. A popular way of presenting requirements in templates is by writing them in the form of user stories.

4 – Not starting with the obvious

You might think that this would be compulsory learning in Requirements 101 classes, but incredibly one of the worst mistakes people make when writing requirements is to overlook the most obvious ones!

Although you cannot realistically expect to identify all the requirements a particular system needs, there are however some which crop up time and time again, and you should always be on the look-out for them.

The problem with omitting requirements is that by implementing them too late in the project it will increase development costs and potentially risk delaying the release of a product.

On our blog, we actually prepared a handy list of 14 requirements you should always consider when writing your list.

Read them here:

7 Requirements you should never overlook (Part 1)

and

7 Requirements you should never overlook (Part 2)

5 – Thinking you have finished the job early

In projects using conventional methodologies, requirements were usually written at the beginning and then passed on in a definite and complete form to the development team.

The biggest drawback of this method is that you cannot expect to foresee every single requirement the finished project will have.

Spending time imagining what you should put down next is wasteful; you would be better off sending a partial (though well-thought-out) list of requirements and then adding to it as new feedback flows in from the developers’ and testers’ side.

In Agile, requirements evolve in parallel with the developing project. As you start gaining a clearer picture of what the product looks like and what it does, you’ll start thinking of new and better requirements to pencil in and cross off obsolete or redundant ones.

Coming full circle

Requirements writing has become a more dynamic and open process that must be integrated with the other departments for a more holistic and agile development experience.

Whilst the increased load of information that has to be handled by requirements may seem intimidating, what keeps one working effectively and purposefully is a good strategy. One that unequivocally explains the principles and motivations behind the team’s efforts in creating functional and user-friendly software.

About the author

 Ulf Eriksson is one of the founders of ReQtest, an online bug tracking software hand-built and developed in Sweden. ReQtest is the culmination of Ulf’s decades of work in development and testing. Ulf is a huge fan of Agile and counts himself as an early adopter of the philosophy, which he has abided by for a number of years in his professional life as well as in private.

Ulf’s goal is to life easier for everyone involved in testing and requirements management, and he works towards this goal in his role of Product Owner at ReQtest, where he strives to make ReQtest easy and logical for anyone to use, regardless of their technical knowledge or lack thereof.

The author of a number of white papers and articles, mostly on the world of software testing, Ulf is also slaving over a book, which will be compendium of his experiences in the industry. Ulf lives in Stockholm, Sweden.