Requirements in multiple groups
To help manage large numbers of requirements, they are always organized in groups. In our experience, around 15% of requirements belong in two or more groups. For example, the requirement:
Control data deletion
The system should control who can delete data and what data they can delete. Where users can delete data, it should be possible to view the deleted data, or even restore that data if necessary.
Could belong to the following requirement groups:
- Compliance \ Audit controls
- Security \ Access control
- Usability \ Data entry
If this requirement was on an evaluation that had 8 products, the requirement would appear on that evaluation 27 times: 3 times on each of the 8 product tabs, and 3 times on the master list of requirements.
What is needed is a system that has normalized requirements: one requirement can be in multiple groups and on multiple products. Edit the requirement anywhere and it updates everywhere.
Groups of requirements need to have relative weights. In practice, those weights are adjusted towards the end of an evaluation when the requirements are better understood.
Group weights tend to be hard coded into the spreadsheet. When a group weight must be changed, it must be changed in multiple places. Again, manually keeping denormalized data consistent is difficult.
Googles spreadsheets allow multiple people to edit the same spreadsheet simultaneously, a huge advantage because it prevents multiple versions of the spreadsheet from proliferating. Microsoft has introduced this same feature into Office365. However, enterprise evaluations are large, and in our experience, large online spreadsheets can be excruciatingly slow. The alternative, a local Excel spreadsheet, always leads to the problem of reconciling multiple versions of the same spreadsheet.
The whole idea behind evaluating multiple products is to score them relative to your particular requirements. This is the gap analysis. When doing the gap analysis on a spreadsheet you need to design a scoring system. This should take into account the weights of various requirement groups and the weights of the individual requirements in those groups.
Scoring is made more difficult by the lack of variables in formulas. The usual way to overcome this is by adding an extra column to hold the variable, and then hiding that column. Manually keeping the scoring formulas consistent across a large evaluation is mission impossible. Even if you do manage to make formulas consistent, there is no way to know those formulas are consistent.
Enterprise evaluations are large, and you always need to search requirements, for example, to see if a potential requirement already exists. A simple search is easy in a spreadsheet, but advanced searches need to be built. While this is not particularly difficult, the spreadsheet is starting to turn into a programming project.
Sign up for Computerworld eNewsletters.