Requirements with or without Excel

What is the most frequently used software for managing requirements? Rational Doors from IBM, Enterprise Architect from Sparx Systems or Polarion REQUIREMENTS from Siemens? The answer is MS Excel. Whatever the large and small manufacturers of requirements engineering solutions try to do, MS Excel is used in many companies worldwide. And not only for capturing and managing requirements, but also for planning and controlling projects or managing changes. Why is that so? Why do many companies rely on MS Excel, where does it make sense and where does it not make sense?

Working in a team

I use Excel. Privately. Rarely professionally. It is ideal for me to manage expenses and income, to calculate surpluses or losses. Occasionally I have to adjust stored formulas, but often it is only minor corrections. Excel is simple. Even macros or pivot tables can be created with a little practice. Of course it runs on my computer for free. A simple scenario, a “walk in the park”. A similarly simple scenario is also possible in a professional context: A small team uses Excel as a filing system, for managing tasks or for recording requirements. For small teams, the distribution of tasks is often done by shouting: “Peter, please create the Excel list with the most important properties. Or: “Bettina, why don’t you copy the structure of the old Excel file and put it on the net?” A greater coordination between the team members and also a separate training are usually not necessary. Of course, all those involved should make sure that there are no different versions of a file, for example by saving it on local data media or sending files frequently by e-mail. Such hints or rules are easy to communicate, so that working with Excel can also work in a team.

What happens if we change the setting slightly? On closer examination, teamwork only makes sense if the Excel file is rarely accessed, e.g. in a relatively small team whose members access the file occasionally and sequentially. With any other setting, for example if the number of times the file is accessed increases because the team size increases, or if the Excel file is used as a central work tool that several, many or all members of the team need to access at the same time, teamwork already does not work as well. Also, the joint editing of Excel files using fixed shares and the Excel option of being able to edit the file with several users at the same time sounds much easier in theory than it ultimately is.

Access to the requirements

Anyone who manages requirements in an Excel spreadsheet should answer a few questions:

• May several colleagues work on the contents of the file at the same time?
• If parallel processing results in changes to the content of a piece of information, which change applies – the last saved one or are there other, more sensible mechanisms?
• Who is allowed to access the information at all, who is allowed to read or change requirements, who is allowed to add new requirements or delete existing ones?

There are companies that use MS Excel in combination with a version management or configuration management system. In such a system, the files are backed up with a user ID and a time stamp each time they are changed, so that it is always possible to trace who changed what in a file and when. The version differences between any versions of a file can be compared and earlier versions can also be restored. The manual versioning that users like to do in the file name (“Afo-CompanyABC-Version-1.2-from-2018-03-14.xlsx”) is completely eliminated. Access to information as well as read, write, change and delete rights can also be defined. Sounds good and secure, right? In fact, a combination of MS Excel and configuration management software only works at the file level; it is therefore possible to define who is allowed to access a file, but not who is allowed to change any specific information in the file. Professional requirements engineering solutions offer considerably more possibilities here. If the solution used is then still client-capable, clients or different customers can also access pre-defined areas and information, but do not see all the available information. This is a clear advantage over requirements management with Excel.

The standardisation of requirements

Have you ever received an Excel file from a colleague whose structure you did not like? Have you perhaps ever found a formula in the Excel file that was implemented in a complicated way? Those who work with MS Excel give every employee the opportunity to adapt the structure of a file according to their own ideas. This can be useful, because as soon as a structural adjustment is agreed in the team, it can usually be implemented quickly. However, if there is no coordination with colleagues, a well-intentioned change could not only be a source of joy. And even if the adjustment makes sense, who makes sure that this change is integrated into comparable Excel files currently in use?

Standardisation often seems easier than it actually is. Without standardisation, people work with a requirement ID in one project and not in another. Furthermore, the typification of information in Excel is also difficult – in project A, an ID could be called “Project_Afo short name_Afo number_Version”, in project B simply “A number”. Within individual projects this would not be bad, but as soon as work is done across projects and features are integrated in different solutions, things quickly become confusing. The standardisation and typification of information is also a clear advantage in professional requirements engineering solutions.

The clarity of information

Speaking of clarity: Excel files can be very clearly arranged. Column and row designations, the use of colours or the temporary use of functions such as “predecessor” or “successor” help with structuring and offer orientation. This also applies in principle to the administration of requirements in Excel. But what happens if you want to manage other information such as sketches, graphics, screenshots etc.? Do you copy them into a cell or do you link the information and manage the data outside the Excel file? If you now want to send the file by e-mail – does the access to the information still work?

Imagine a requirement changes – what do you do then? If you overwrite the existing requirement, you will no longer be able to reconstruct how the requirement was originally formulated. If you insert a new row below the existing requirement, do you hide the original one? How do you update relationships between the original request and test cases, effort planning or already invested working time? Where do you manage the test cases for a specific requirement? Can the test cases be easily grouped into test runs? And where do you keep track of why a requirement has changed; maybe link to additional documents or emails you have received from the customer?

The amount of information per element often grows rapidly in requirements management and is usually far too comprehensive, making it impossible to display information clearly in Excel. In contrast, many database-supported solutions present all information in the context of a requirement – e.g. with adaptable forms or definable view concepts – in a clear and comprehensible way.

The exchange of requirements

If you want to cooperate with a company and exchange requirements, Excel could help you. You can simply email your partner the file that he is most likely to be able to read and transfer to his system by mapping the information. Even direct editing of the contents in the file is of course possible and the effort to work with different Excel files and structures from different companies is probably limited. Although this requires good will on the part of the employees, it works relatively well. If communication with the cooperation partner about the contents takes place, it might even be possible to work in the delivered file and integrate new information there. Stop. Is such a procedure safe? If the file is repeatedly exchanged, how can it be ensured who changed, rejected or accepted which information? With few requirements you may still have this in mind, but what about 100, 500, 1000 or 5000 requirements? Wouldn’t it be better here to rely on a standard that was developed exactly for such a scenario? The standard is called ReqIF.

ReqIF stands for “Requirements Interchange Format”. It was developed explicitly for the exchange of requirements and has none of the weaknesses described above. And why is the exchange via ReqIF better than the exchange via Excel file? Imagine a customer sends a requirement to his supplier, who returns it with the status “Accepted”. In the meantime, however, the client has extended the request. Of course, the extended request is no longer “Accepted”. In Excel, a manual adjustment must now be made by an employee who recognises the context and adjusts the status. In a professional requirements engineering solution, this happens automatically and therefore working is much safer, easier and more transparent for all parties involved.

Conclusion

MS Excel is a great tool. It is very easy to use in the private environment to manage information and calculate data. Also the work of smaller teams in organisations can be made easier with Excel. But as soon as several employees have to work on the contents of an Excel file in parallel, it becomes difficult to use. Access to information, versioning of data, editing rights, clarity and traceability, standardisation and typification – there are many reasons against using Excel in requirements management. The fact that training of employees is rarely necessary speaks in favor of Excel. Furthermore, Excel is already installed on most computers in a company and, especially in comparison to the additional costs of a software selection, this seems favorable at first glance; however, practice shows that an investment in appropriate solutions quickly pays off as soon as a professionalisation in requirements management is achieved.

Notes:

Here you can find information about IBM’s Rational Doors.
Here you can find information about Enterprise Architect from Sparx Systems.
Here you can find information about Polarion REQUIREMENTS from Siemens.

Michael Schenkel has published more articles in the t2informatik Blog, for example

t2informatik develops and modernises software as a service provider. Click here to learn more.