This is the final article in a series of five blog posts on requirements documentation. Where documenting requirements is considered a de facto standard in classical projects, Agile contexts tend to avoid it, as it is seen purely as unreasonable extra effort. We have analyzed where this perception has come from and how the documentation can be performed within agile projects in a way that emphasizes its benefits. To this end, we started with an investigation of why requirements are documented at all in the first part of this series. Part 2 addressed how requirements documentation was never meant to be dropped from agile development but remains an integral part of the development approach. However, making requirements engineering work in agile settings involves tackling particular challenges, which we discussed in part 3. In part 4, we addressed how to overcome the hurdle of preventing chaos resulting from a proliferation of documentation. In this final part, we analyze which tools can be used for requirements documentation to represent an enrichment in agile contexts.
A requirements documentation process requires tool support, for which different kinds of tools can be used. For example, in agile development settings, the use of wikis and issue tracking systems has become the de facto standard. However, despite their benefits for agile development, such tools also have their own distinct downsides regarding requirements engineering. Depending on their concrete type, tools facilitate the storage of requirements in the short and long term, grant access to stakeholders with the right clearance, manage relationships, provide artifacts in different formats, or assure the quality of both the requirements specification and the project as a whole.
Together with OSSENO Software GmbH—a spin-off of Fraunhofer IESE and with whose co-founder Dr. Sebastian Adam we are writing this blog entry—we have explored which factors affect the choice of the most suitable tool or set of tools for a particular project or work setting, such as the ease with which requirements can be documented, the necessary degree of requirements management, the fulfilment of sustainability requirements from industry standards, or the desire to reuse requirements in further projects. In order to make such an assessment, we need a better understanding of the strengths and weaknesses of each type of tool. This is why in this post, we will provide a rationale for using tools for requirements engineering and introduce different types of tools according to a maturity model.
The Purpose of Tools in Requirements Engineering
Professional software and systems engineering is not scalable without tool support. Even though the agile value “individuals and interactions over processes and tools” highlights the importance of interactions within the project team over the use of tools and processes, the latter are nevertheless indispensable means for making projects effective and efficient.
Besides tools for coding and testing, a software-developing organization also requires tools for managing and tracking the project requirements. Without a clear overview of the requirements to implement and the tasks to perform, planning and controlling a project is nearly impossible.
Independent of the development context—agile, traditional, or hybrid—tools in the context of requirements engineering aim to provide support for requirements documentation and management activities, i.e., for making requirements available and trackable over time in a digital form for all persons involved in or affected by a project.
Besides specialized tools for requirements engineering, known as Requirements Management (RM) tools, other types of tools initially developed for other purposes have found application in requirements engineering, too. The German RM vendor OSSENO Software has defined a maturity model for tooling in requirements engineering (see figure) that categorizes tools into five categories of tool types, ranging from basic office tools to advanced RM tools.
Overview of Requirements Engineering Tool Types
Office tools, such as Word or Excel, are used in almost every organization. Because of their universality and their daily use, they do not impose any entry barriers and are therefore the easiest choice for people assigned the task of documenting requirements. In fact, office tools are still the most frequently used tools for requirements engineering, even though they do not provide any specific functionality for this task. Nevertheless, they allow documenting and storing requirements in a digital way and organizing them into chapters (Word) or in a matrix (Excel). Despite the benefit of using very common documentation formats that allow an easy exchange with other people and tools, document structures are hard to maintain because there are no restrictions and everything can be modified, and the quality of the requirements themselves strongly depends on the authors. In addition, requirements management practices such as traceability, versioning, workflows & views, or analysis & reporting require a great deal of manual effort.
Wikis, such as MediaWiki or commercial enterprise wikis such as Confluence, are used in many organizations to establish a joint and central knowledge and information repository. Because of their universality and ability to link content from different people, they are nowadays a popular means for requirements documentation. Even though they do not provide specific features for requirements engineering, they provide basic mechanisms for collaboration, versioning, and linking that are helpful for such a purpose. Their support for requirements documentation and management generally have the same limitations as office tools do, except that they do provide support for linking and versioning.
Issue tracking systems, such as JIRA, are popular tools for organizing work items and tasks in development projects or service organizations and are therefore widely used. Even though they were not originally intended to support requirements engineering activities, several companies have started using these tools for this purpose because in contrast to the aforementioned tool types, issue trackers allow requirements to be documented and tracked very well in an atomic manner. They are therefore also suited for supporting workflows. However, issue tracking systems often suffer from compatibility issues with other tools and were not designed to contain a large number of requirements, so in larger projects, the entire set of requirements can quickly become overloaded. Moreover, they provide only limited support for analysis and reporting, and for venturing out too far beyond the predefined structure of the system.
Classic RM tools, such as DOORS or Polarion, explicitly aim to support the specific tasks performed during requirements documentation and management. Unlike the aforementioned tool types, RM tools offer specific functions to support requirements engineering activities. These can include the creation of views on subsets of requirements, reporting, automatic import and export of requirements, baseline management, and systematic reuse. Even though they usually do not provide functionality that helps with performing other requirements engineering activities such as validation or elicitation, they support at least the organization of requirements very well, supporting many aspects not covered by the previously discussed types of tools. Unfortunately, this often comes at the cost of ease of use and learnability of the system, which typically means that these tools can only be used by experts.
Advanced RM tools, such as ReqSuite or Qualicen Scout, provide intelligent work assistance in addition to the aforementioned default features of an RM tool, supporting requirements documentation and management as well as elicitation and quality assurance activities. Another differentiator to the more traditional RM tools is their ease of use, because they try to hide and encapsulate complexity from the end user. They provide support for processes and collaborative settings specifically to support non-experts as well, for example through intelligent recommendations on what steps to take and how to document requirements, and by performing quality checks on text-based requirements regarding aspects such as completeness, consistency, and linking. As with classic RM tools, however, they do require configuration effort, limit the degree of freedom to modify the predefined structure, and are only partially applicable for tasks other than requirements management.
Modeling tools form an additional category of tools used in addition to tools for documenting and managing requirements. Because these tools do not aim at supporting the requirements engineering activities of documentation and management, they are not part of the maturity model; rather, they should be considered a complementary type of tool that plays an important role in requirements engineering. Especially for illustrating complex aspects of a system, models are often used to make those aspects more comprehensible. In this regard, modeling tools help to enrich textual requirements with graphical information such as UML or BPMN diagrams, or with screen mockups. Popular modeling tools are Enterprise Architect for UML, Adonis or Signavio for BPMN, or Balsamiq for user interface design. They can therefore be considered a complementary family of tools, whose results (i.e., model images) can be stored as attachments to the textual requirements in one of the tools mentioned above.
Choice of Requirements Engineering Tools
Requirements engineering requires tools. Depending on the individual project situation and complexity, different tool types are most suitable. While office tools can still be applied in rather small and traditionally styled projects, wikis and issue tracking systems are a good choice for agile projects of medium size. However, for long-term projects or larger projects, specialized RM tools appear to be a better choice. Especially advanced RM tools can bring great benefits in settings with a high number of requirements and/or a limited experience of the people involved because manual quality assurance and correct adherence to a systematic refinement approach are nearly impossible in such a situation.
Fraunhofer IESE has extensive experience in assessing the circumstances under which a particular tool type is adequate, partially adequate, or not adequate. Contact us if you need advice on picking the best suited tool or set of tools, and/or support with introducing tool support within your organizational context!