Every role in an organization has the tendency to see his/her task as a silo: e.g. we deliver requirements in an un-manageable Microsoft Office document and let the readers decide what they want to do with our requirements. Some organization begin to use integrated tools like HP’s tool suite. Although not the best tool for requirements engineering, HP provides an excellent tool to manage requirements, test cases, and the traces among them. When deciding whether the HP QC licenses are enough or HP ALM should be used, there are certain features of HP ALM that are a must.

Wouldn‘ it be great if teams from different silos would collaborate and use the same integrated platform? Business analysts and requirements engineers write their requirements and specifications, the requirements manager has all information about the requirements at his fingertips, the release manager and development team understands which requirements are planned for which sprint and release of the applications, the test manager knows beforehand which requirements are planned and can prepare test cases and testing activities, and the tester knows which tests have to be executed based on which requirements.

Does that sound like collaboration utopia?

Maybe it does. My last employer has embraced this utopian approach for the past three years and has made some observations about the specific tool being used: HP ALM. Of course, there are other tools that may seem more modern. Fundamentally, HP ALM is based on the same data base as HP QC. The difference lies within the license and the functionality provided to the user. Basically, QC allows a tester to do his magic. As soon as business analysts, requirements engineers, or requirements managers begin to use the tool, certain functionality is needed that only HP ALM provides.

Of course, HP ALM has its quirks, especially in the text and rich text fields which change the text and table structure at their free will. According to HP, everything is a lot better for requirements with version 12.

Word-like Export

We have learned that everyone wants a Word-like document to read, understand, and review the requirements. The more agile teams are the more documents will have to be created. At least one for each sprint, maybe multiple: one for all business requirements, one for all use cases, one for all user interfaces/storyboards, and so on. The more requirements have to be managed in the tool, the higher the possibility will be that a user will have to filter the requirements to only select those that are relevant or approved. e.g. for a sprint.

And that’s where both HP ALM and HP QC have a bug. As soon as a filter is used to create a Word-like document, the tool cannot recreate the structure already defined in the requirements tree because it may filter out requirements that are nodes for child-requirements and that are needed for the structure. The result is a structureless mess.

The only workaround to cope with this bug is to use baselines (or develop a complex workflow mechanism).

Baselining

As soon as the tool is used to write requirements just like in a Word document, a user wants to create versions of the overall document. By creating a baseline, a user can tag all requirements that are to be in that version of the document. Both, HP QC and HP ALM allow to do draw baselines. The user will then want to select that baseline and export the version of a document created from that baseline. Only HP ALM allows to export a document from a baseline. Without that functionality, baselining seems worthless in the tool.

Cross-Filter Word-like Reports

Sometimes users need a Word-like report using a cross-filter, e.g. ‚export the detailed requirements traced from my business requirements‘. That’s possible using ALM but not QC.

Manual Workaround

If a user wanted to use HP QC for creating Word-like documents from filtered requirements, a user would have to try to manually recreate the structure after each export. The user would have to manually add missing nodes (chapters) and manually reorganize the requirements into the manually created structure. The difficulty lies within the need to not just copy the name of the missing requirements to be used as chapter nodes but also the missing text of the requirements.

The effort per document depends on the deepness of the structure and the number of requirements. Of course, the effort depends on the number of tries to create the document as well: if an error in the text is noted and the document has to be created again, all the previous effort to manually create the structure is lost.

My estimate is that it takes 15 minutes on average to recreate the structure of a document containing 10 requirements, 1 hour for 50 requirements. Projects having 500+ requirements would therefore need 10 hours every time the document is created. Depending on the number of times this manual workaround will have to be done, the higher license fee for HP ALM will quickly make sense.