Introduction

Whenever my wife sends to me to buy food I have fear. I have a fear that I’m not buying the right food, even if I try to do my best. The issue is that I go to the shop and check my list, the first point is “milch”. And at this point I have no chance to fulfill the requirements. I can not fulfil them simply, because they are not proper. How much milk? Which brand? How many percent of fat should be inside etc. etc. What can I do? I can call my wife. She’s not available...at least most of the cases. Then let’s do some assumptions and by two liter of the most famous brand. In 99% of the cases it was not really what my wife expected...So how can make it better? I can check her list before leaving home and think about the potential questions, so just ask: “and how much milk do we need?” “which branch do you prefer” etc. and notice her answers. Once I think that everything is clear I can leave.

And of course that’s not everything. Sometimes she’s calling me as I’m in the shop: “Sorry, I forgot to tell that we need sugar as well” or “I changed my mind, I cook something else”. That’s something called requirement change.

In other cases I go to the shop and I realize that all beef is over. What can I do (especially if I'm too lazy to go to another shop)? Call her, announce her and try to come up with alternative, like “There’s no beef, but what about chicken?

And since my goal is to be a good husband I do everything to make my customer (khm wife) happy. And since I’m also a lazy programmer, I try to avoid double work, which is in this case the situation that I need to go back to the shop again.

This is something called requirement engineering on high level: try to understand the customers expectation, document them in a clear, non-ambiguous way, think about corner cases, make questions in case of uncertainty and track also the change requests. As a requirement engineer you are the transfer layer between the client, who is often not technically deep in the topic, and the programmer. You need to translate from the language of the customer to the language of the programmer. At some companies it is a dedicated role, but in several structures it is also a task for the developers.

Functional and non-functional requirements

There are two big groups of requirements: functional requirements and non-functional requirements. Functional requirements tell information about the functionality: what should the software do. Most of the requirement are functional.

Non-functional requirements are for example defining the environment (which operating systems are supported, which other programs needs to be installed) or the hardware needs (minimum RAM etc.).

How is a good requirement?

A good software requirement is unambiguous, clear, easy to understand, testable, atomic (can not be split into multiple requirements) and independent from the implementation. Practically you should avoid the complicated phrases, use simple sentences without “and” and “or” and always think on the level of user. That means don’t write that “the database layer should do … “. The user has know idea about the database layer. The requirement should be written really on the level of user. Usually the requirements are in present mode and built up by using the world should and shall. Example: _“By clicking on the load button the “Open file” file browser window should be opened.” _

It is also good if you are attaching a high level test cases, how to test your requirement. It makes it more understandable.

How to document requirements?

The requirements needs to be documented in a version controlled format where all changes are stored and traceable. Each and every requirement need to have an identifier, so that it can be linked to test and to design/implementation. The requirements needs to be ordered. A good strategy is to order them by features. By reading the requirements the reader needs to get an overview about the software, so the requirements needs to be written in a structured way.

There are several software which are specially designed to maintain requirements, but they can even be stored in a simple text file.

Certain versions of the requirement document needs to be shared with the customer and discussed point by point.

How to handle requirement changes?

Requirement changes needs to be also documented in the following format: what has changed to what, which time, what’s the purpose of the change and in which software version need the related functionality be changed. With this manner you can avoid a lot of discussion with the customer.

Requirement and agile?

In most of the classical agile processes (Scrum, Kanban etc.) the requirement engineering is not part of the process, a requirements are documented in user stories and their can be overridden by any later user story. However in such an environment it is also possible to have one central collection of requirements and in case of complex systems it can help a lot on long term.

Summary

Of course requirement engineering is a complex topic and this short post can not go deep enough. Some people also things that requirement engineering is old fashioned, but based on my experiences it is very useful if you are working with clients, it can make your life much easier.