When we develop standard software or implement it with customers, all requirements for the IT system itself, as well as for all relevant interfaces, must of course be elicited. According to Klaus Pohl in his book Process-Centered Requirements Engineering: Advanced Software Development, they must also be "expediently documented, reviewed, and reconciled, and the documented requirements must be managed over the entire life cycle of the system."
And this is where the challenge begins. You often find Word documents distributed by email linked to Excel documents that are stored somewhere. And you constantly need to clarify which document contains the requirement descriptions that are currently applicable. Is the status on the cover sheet correct?
It is not uncommon for stakeholders to have to be asked to confirm or approve a requirements specification before the actual implementation can begin. In most cases, there is not just one stakeholder who is supposed to approve the requirements specification, sometimes there are two, three or more. That's when it starts to get complicated. If you're unlucky, the text has been adjusted by each reviewer, but, unfortunately, without activating the change mode. In this case, at least two documents need to be compared and merged again. And if multiple rounds are required to clarify the requirements, this can happen two or three times.
And how is the degree of requirements implementation or the implementation of the other to-dos related to the requirements clarification process? Such as with the procurement of detailed documentation, interface descriptions or process diagrams.
Does that sound familiar? Then here's a suggestion on how to make that process more efficient.
What are the goals of requirements management?
The first is to maintain a transparent requirements description during collaborative work. Especially when several people are working (simultaneously) on one document. Changes should continuously be tracked, which means that the document will go through numerous different versions (versioning).
This should enable the specification and review processes to be traceable, as well as the documentation of decision statuses and approvals.
You should display the processing status for the implementation of (detailed) requirements that were obtained when the requirements were elicited. This is so that you can facilitate the oversight and tracing of the to-dos.
Ultimately, a decision and document archive will be established and continuously maintained.
Atlassian Confluence with Comala Document Management as an extension
Confluence is a widely used commercial enterprise wiki software solution for working in collaboration, documenting, and communicating and sharing knowledge in enterprises and organizations. It was developed by the Australian company Atlassian.
In the standard Confluence system, it either isn't possible to define workflows, or it can only be done via cumbersome workarounds. This is certainly not a solution for the vast majority of users, though it's still more efficient than a text file email hail mary, right?
This gap in Confluence can be closed with the Comala Document Management Confluence extension. With this extension, quality management processes, technical documentation, editorial publications, and policy document maintenance can be efficiently supported.
Simple read receipts can be implemented. However, more complex workflows for review, approval and acceptance processes can also be mapped and their execution documented in a way that can be revised.
Requirements from standards like ISO 9001 can thus be met. This is an important additional value.
In concrete terms, what could requirements management look like?
Basic functions in Confluence
A product owner or requirements engineer describes the requirements within Confluence. Other stakeholders can submit their notes or additions as text adjustments or as comments on this page. Each change is automatically versioned and can be compared with other document versions at any time, or even restored.
Outstanding issues or questions can, for example, be recorded as "tasks," or have a target date and one or more authorized Confluence users added to them. These tasks are then displayed in the respective individual Confluence profiles and can be accessed and edited.
Of course, several functions that need to be implemented individually are described in this type of specification. These could perhaps be recorded immediately as implementation tickets in the company's own ticket system and linked to the Confluence page.
If, for example, Atlassian's JIRA ticket system is used in parallel, these tickets can be linked very easily at a point where it is suitable. There is also the option of displaying a summary of the ticket, including definable detailed information (such as the processing status or assigned employees).
This would also enable a function's respective implementation status to be immediately tracked on this specification page. The specification page can thus be utilized as a documentation of the functions and requirements that have actually been implemented.
If the requirements change over time or are modified, these adjustments to the requirements can be recorded again on this page.
Review and approval processes with Comala Workflow
At some point, you will want to finalize the requirements specification so that you can start implementing it. Or, so that you can complete the creation of a documentation process. You thus settle on a description status that all stakeholders have agreed upon.
To do this, you can activate one of the included workflows with four mouse clicks on one page. Of course, you can adapt existing workflows or develop completely new ones.
We keep everything simple here and opt for a very simple approval workflow. A requirements engineer, for example, activates a workflow with an approval stage. You then specify the Confluence users who should approve this page, and you're done. The reviewers can now give their approval with two mouse clicks, or deny it, if necessary, with a comment. In practice, people are more likely to talk about the need for customization, adjust something, and then start the workflow as the final step.
If a change is made to a page after it has been approved, the page status automatically changes back to the status it had before the approval. Which one exactly depends on the workflow. The version that has been approved is archived, but can be viewed at any time. Also, the approved version can be displayed again at any time.
Altogether, these procedures can be used to achieve compliance with standards such as FDA Title 21 CFR Part 11, ISO 9001, ISO 13485 or GxP. The revision of the ISO 9001 standard in 2015 also opened up the option of meeting the requirements for a quality management manual through the use of a wiki solution. The ability to ensure that processes are followed is very relevant with regard to compliance.
In addition, when the first Comala workflow is recorded, a separate overview is automatically created in Confluence for the relevant Confluence area. This records all pages with Comala workflows and provides an up-to-date list of workflow statuses and further details about this page. Very convenient for project management.
Of course, there are other ways in which the goals mentioned at the beginning could be achieved differently. For example, one option would be to use Microsoft Power Automate in conjunction with markups on Teams and SharePoint. However, since Confluence is very widely used as a "documentation basis," this version should nowadays be presented with its basic features. This is because the combination of Confluence, Comala Workflows, and Jira would have even more to offer.
Want to talk to one of our experts about how our software helps modernize insurance IT? Then feel free to contact Karsten Schmitt, Head of Business Development at adesso insurance solutions.