Requirements Management with JIRA and ReqSuite® RM

Requirements Management with JIRA

Atlassian's JIRA has made a remarkable move into a wide range of companies in recent years and it is more than a feeling that almost every company in which software development plays a role is now using JIRA (or similar products such as Microsoft's Team Foundation Server). Originally used as an application for error management, problem handling and operational project management, more and more companies are also using JIRA for task and requirements management within (agile) software development. Evil Tongues are therefore not entirely wrongly saying that JIRA is the new Excel, i.e. a tool with which companies try to kill as much as possible.

With regard to requirements management and other requirements engineering tasks, the question is therefore justified as to what benefits JIRA can deliver in this environment. There is no doubt that JIRA offers some basic functionalities for requirements management and can therefore keep up with explicit requirements management tools (RM tools) in parts. Nevertheless, more and more companies are realizing that the use of JIRA (or similar tools) does not automatically result in project success or that communication between department and IT can only be partially improved. If the project participants do not have a sufficient methodological basis, the old saying “A fool with a tool is still a fool” or the even more drastic insight “Shit in, Shit out” also applies in this context.

There is no doubt that JIRA offers interesting options for task management and the associated status control before, during and after development. But to even know which tasks need to be completed (i.e. which requirements need to be implemented in a specific sprint or release), you need more than that. Good requirements engineering still includes key questions such as:

• Who are my stakeholders?

• What are your needs?

• Which system properties and capabilities (requirements) result from this?

• How important are these requirements in each case?

• How are the requirements related to each other and what refinement is there between them?

• Have we forgotten or insufficiently specified important requirements?

• etc.

Well-known tools on the market can of course barely answer this question, if at all. The benefits of JIRA, but also of other well-known RM tools, in terms of the quality of requirements therefore still depend solely on the individual expertise of individual project participants.

‍

The ReqSuite® requirements management software

With Osseno's ReqSuite® (see Figure 1), however, a tool for requirements management has been presented in recent years that also supports content-related and methodological issues and can ensure the quality and completeness of requirements right from the start through intelligent assistance functions. Similar to a program for preparing income tax returns, which also supports inexperienced people in the correct and complete preparation of standardized tax returns, ReqSuite® offers concepts to develop (sufficiently) good requirement documents in a standardized manner regardless of personal expertise in the area of “Requirements Engineering”. The ReqSuite® assistance therefore also provides assistance in answering the key questions mentioned above and also points out incompleteness or inconsistencies directly during the requirements documentation. The saying “A fool with a tool is still a fool” is therefore only limited in this context.

‍

The benefits are obvious and have already been confirmed by a large number of customers: Ambiguities and incompleteness that result in costly rework before, during or even after development are proactively reduced. At the same time, there is always an overview of aspects that are still insufficiently clarified, which (unless you develop in a waterfall) is decisive for success, especially when defining ongoing sprints parallel to the analysis of ongoing sprints. Finally, ReqSuite® also automates formulations and formatting so that users can focus entirely on the content of requirements and less on their syntax. After all, this not only creates more freedom for content work, but also increases the acceptance of requirements engineering, which is sometimes often perceived as heavyweight and antiquated, as a whole.

But should you switch off your established JIRA now and only work with ReqSuite®? Definitely no! Even though the correct answer must always be answered on an individual basis, it can be said in principle that JIRA offers a variety of valuable features for many work steps in software development that ReqSuite® has not yet wanted to adequately substitute. Nevertheless, ReqSuite® offers enormous added value for requirements engineering and similar disciplines, which can only be insufficiently achieved by JIRA and its extensions and accompanying tools such as Confluence.

Accordingly, it is promising to look at the joint and integrated use of JIRA and ReqSuite® below.

Methodological integration

The methodical integration of JIRA with ReqSuite® is heavily dependent on the business and development context you are in. On the one hand, this concerns the object of development (e.g. the development of an existing system in insurance versus the development of a control module in mechanical engineering), but on the other hand also the scope of development activities (e.g. project vs. portfolio).

Nevertheless, the following best practice can be postulated for integration across contexts:

“ReqSuite® manages the content (including requirements) and JIRA manages the tasks within a portfolio or project. ”

According to this best practice, when integrating JIRA and ReqSuite®, it makes little sense to copy the content of ReqSuite® one-to-one to JIRA and virtually create redundancy in both tools. Instead, a content abstraction level should be defined which can be used as a suitable starting point for synchronization.

The main challenge in methodological integration (but also in defining a clean methodological procedure in general) is therefore to define the content refinement structure from requirements down to the level of development activities. As a rule, there is no general model for this, as this structure depends significantly on the object of development. In the environment of an operational information system, this structure could include requirements with regard to business processes, organizational units, use cases, system functions, business data and interfaces, which would have to be adequately mapped to appropriate development activities (read also our white paper on the definition of tailor-made requirement processes).

Therefore, for the purpose of this article, only an abstract refinement structure can be shown, which represents a possible division between ReqSuite® and JIRA (see Figure 2).

‍

According to this model, ReqSuite® includes information about stakeholders, their context, their needs, and the resulting topics, projects, and requirements. In addition, the development activities resulting from the requirements are maintained in JIRA. Projects and project participants may be maintained redundantly in both tools.

If stakeholders now report needs, these are specified in the form of topic descriptions within an associated portfolio in ReqSuite®. After appropriate review and prioritization of the topics, portfolio or program managers can then map them to specific projects. Within projects, ReqSuite® then offers the above-mentioned assistance functions to adequately support project participants in successive and quality-assured development of project requirements, taking into account the context.

Development activities (tickets) can then be automatically derived based on the requirements and exported to the associated JIRA project at any time, but also at fixed, points in time. If configured, this can also be automatically assigned to the project participants responsible for implementation. After completing your tasks accordingly, you can then update the status of your activities, which is then automatically reflected back to ReqSuite during the next synchronization and thus documents the fulfillment status of the requirements.

However, an important question at this point remains how individual (system) requirements can finally be mapped to development requirements for respective development activities. This also depends largely on the development context. In the example above, it would be conceivable to gradually break down business requirements through various levels of abstraction, such as business processes and use cases, down to the level of fine-grained system functions, which at the same time represent the content of individual development requirements. For example, the requirement “As a life insurance clerk, I would like to see the buyback value of a contract on the contract overview so that I can provide the customer with information more quickly.” from ReqSuite® would be adopted as a development request (ticket) in JIRA and the resulting development activities would be implicitly visible to developers. Alternatively, however, a further refinement of the requirement into actual activity descriptions such as “adding a readonly buyback value to the LV-UE1 mask” would also be possible. The latter would have the disadvantage of increased specification costs, but the advantage of a more precise task description and more granular tracking.

‍

Technical integration

Integration and consistency issues are a major argument that is sometimes made against using multiple tools. If data can only be exchanged manually or exclusively partially automatically between different tools, this is not only an obstacle to efficiency, but also an enormous source of errors. In addition to methodological integration aspects, technical integration capacity therefore also plays a decisive role. The technical integration of JIRA and ReqSuite® was therefore designed to be multi-level, dynamic and bidirectional.

Multi-level integration

At the top level of integration, projects in ReqSuite® with corresponding projects in JIRA in the form of 0.. * — 0.. * relationship. Any number of projects can be stored in JIRA for every project in ReqSuite®. Conversely, several ReqSuite® projects can also synchronize content with a JIRA project. However, it is recommended that a ReqSuite® project synchronizes content into a maximum of one JIRA project, as from ReqSuite®'s point of view, a clear “buyer” should be defined for each of the requirements. Conversely, however, a JIRA project can consolidate content from various ReqSuite® projects, as editing within development may be organized differently than at the level of technical projects within the subject portfolio.

‍

On the second level of integration, the requirement types from ReqSuite® with issue types in JIRA is also linked in the form of a 0.. * — 0.. 1 relationship. In each project, it is therefore possible to define whether the requirements of a certain type should be exported from ReqSuite® to JIRA at all, and, if so, in the form of which issue type. In the example above, you could therefore set that only “Feature” requests should be synchronized with JIRA (see Figure 3) in the form of the “Task” issue type (see Figure 4). A filter can be defined for this level to include only the elements for synchronization that meet the filter's condition.

Finally, on the third level of integration, a fine-grained attribute mapping between ReqSuite® and JIRA can be defined. In addition to a standard mapping (Name -> Summary and Description —> Description), you can set very individually how individual fields from ReqSuite® relate to JIRA fields. The project participants can also be automatically mapped so that the assignees responsible for implementation can already be defined in JIRA in ReqSuite®.

‍

Dynamic integration

When integrating ReqSuite® with JIRA, great emphasis was placed on flexibility and configurability. As a result, the interface was developed in such a way that hardly any static mappings were predefined, but can be selected completely at runtime. The integrable projects, requirement types, issue types and attributes in both ReqSuite® and JIRA are determined dynamically at runtime and can then be related to each other accordingly. It is therefore also possible to take so-called custom types and custom attributes, i.e. self-defined types and fields, into account when mapping.

Bi-directional integration

Bidirectional integration means the ability not only to transfer content from ReqSuite® to JIRA, but also to mirror it back as needed. When configuring the interface, it is therefore possible to define whether (bidirectional) synchronization or just (unidirectional) export from ReqSuite® to JIRA is desired. In the case of genuine synchronization, the interface is able to merge changes on both sides or, in the event of a conflict, automatically resolve them based on stored rules. As a result, friction losses due to inconsistencies can be virtually ruled out.

When does integration make sense?

Integrating JIRA and ReqSuite® can provide many benefits for requirements engineering and management. In concrete terms, it makes sense to use ReqSuite® in addition to JIRA, especially in the following circumstances.

When the quality or completeness of requirements is inadequate

If the quality, completeness or even standardization of requirements is not satisfactory, ReqSuite® offers excellent opportunities to remedy this. This is often (but not only) the case when it comes to involving less technically savvy colleagues from specialist areas who have little experience in writing good requirements. Letting them write their wishes and requirements directly into JIRA or upstream tools such as Confluence without assistance usually involves subsequent and possibly expensive clarifications and adjustments.

When you lose track

If JIRA contains a wild hodgepodge of issues, feature requests, epics, user stories and tasks without the technical background or conceptual context being apparent, it becomes difficult to reliably master and manage the inherent complexity of projects. In this case, it therefore makes sense to add ReqSuite® to enable reliable recording, linking, monitoring and evaluation of requirements and solution concepts. However, informal tools such as wikis, which are often combined with JIRA, cannot provide adequate support for this.

When documents are required in addition to “tickets”

In many organizations, various documents are required as part of project work, even if agile development is ultimately carried out. Through a cleaner separation of content and representation in ReqSuite®, ReqSuite® can automatically generate all required documents and reports, such as project proposals, technical concepts, IT concepts, acceptance concepts, offers, etc. in the desired corporate design at the push of a button. JIRA is very limited when it comes to generating such documents.

When good cooperation between department and IT is required

If good cooperation between department and IT is desired, a clear separation of content descriptions and development-relevant tasks also makes sense. In particular, it is necessary to adequately address the language of the specialist areas (which think in terms of processes, tasks and documents, for example) and to abstract from technical details or concepts. Another advantage of separating content from development tasks is that specific development tasks, which usually only have to be carried out once as part of a specific project, can be clearly separated from the content implemented therein, which may be repeated across projects (e.g. data glossaries).

When project participants can't or don't want to work with JIRA

Even though JIRA is fairly easy to use, it is still a tool from developers for developers and not one where department employees feel at home. Especially when it is unclear what the requirements actually are and how they can be derived systematically, the specification of simple templates for epics and user stories, for example, is not sufficient to adequately determine the needs of the specialist areas. Here, it makes sense to support the corresponding work through more target group-specific entry masks and assistance functions. While this only requires complex implementation in JIRA, ReqSuite® comes with simple but powerful features out of the box.

Conclusion

The success and benefits of JIRA are undisputed and should not be diminished in any way in this article. Nevertheless, the use of additional tools, particularly on the part of the specialist departments, is desirable, particularly in the case of cross-sectoral cooperation. However, highly promoted products, which are often advertised in bundle with JIRA, offer no real work assistance for project participants and often represent no more than a web-based word alternative; with all the advantages and disadvantages that have been known from working with office products to date. If the above-mentioned aspects exist, consideration should therefore be given to the additional use of ReqSuite® as an overarching and, above all, content-focused portfolio and requirements tool.