![\"Requirements](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2019\/11\/OSSENO-Tool-Requirements-Engineering-698x437.png\")
Overview of Requirements Engineering Tool Types<\/h3>\n
Office tools<\/strong>, 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.<\/p>\n Wikis<\/strong>, 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.<\/p>\n Issue tracking systems<\/strong>, 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.<\/p>\n Classic RM tools<\/strong>, 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.<\/p>\n Advanced RM tools<\/strong>, 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.<\/p>\n Modeling tools<\/strong> 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.<\/p>\n 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.<\/p>\n 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!<\/p>\n","protected":false},"excerpt":{"rendered":" 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…<\/p>\n","protected":false},"author":46,"featured_media":4659,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[211],"tags":[198,127],"coauthors":[80,74,265],"class_list":["post-4494","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-digitale-transformation","tag-english","tag-requirements-engineering"],"yoast_head":"\nChoice of Requirements Engineering Tools<\/h3>\n