fbpx

How to turn a good requirements specification into great results

Have you created a good requirements specification which followed good practice but were surprised that the results were not what you intended? Shared documentation is far different from shared understanding.

A requirements analyst works in a broad spectrum ranging from business to IT, and therefore has the responsibility and opportunity to let different groups speak up to capture the real needs of the business. Therefore, it is important that a requirements analyst can build good relationships, facilitate creative meetings, coach, collaborate and help people express themselves.

The key to success for a requirements analyst is the ability to listen and understand feedback from different stakeholders and then drive change. Requirement analysis should focus on understanding the needs, expectations and what creates value for the end-users and other stakeholders. It is also necessary to continuously collect data and insights in the form of feedback from users in order to identify areas for improvement. The information can be used as the basis for a requirements specification and a desired new position.


Shared documentation does not equal shared understanding

When the requirements specification is complete, it should only be shared with the developers who can start building what is there. Crystal clear, right? Not really. Simply handing a requirements document to developers without dialogue will cause problems, as it can be interpreted in unexpected ways, which itself can cause unexpected results.

Shared documentation does not equal shared understanding. All the necessary information is not included in the requirements specification and it is difficult to reflect the knowledge and insights created in a collaboration between people in just a few lines of text. So instead of creating the requirements analysis on your own, it’s good to collaborate with members from the entire development team. Only then you can reach consensus on the upcoming job.

Don’t forget to communicate

Everyone has different interests; the developer wants to write code, the tester to test and maybe there is not enough time to do all the steps together. In these cases, it should nevertheless be a minimum to have a dialogue about the requirements before the coding starts. In the dialogue, the developers can ask questions and discuss the thoughts at an early stage, which provides better conditions for a smoother development.

Improved communication reduces the risk of undesirable outcomes from an otherwise well-executed work with requirements and leads to a corresponding likelihood that the result will be as expected. Cooperation also has other positive synergies, namely that those who participate in the creation feel joint ownership and share pride in the result. If other team members also understand the underlying needs, it will be easier for them to contribute with good solutions for the problems, and it can also affect what requirements are set.

 

Joakim Kulo, Tagore