Introduction
Requirements management with JIRA
Atlassian’s JIRA has made a remarkable entry into a variety of companies over the past few years and it is more than a feeling that almost every company in which software development plays a role now uses JIRA (or similar products like Microsoft’s Team Foundation Server). Originally used as an application for error management, problem solving and operative project management, more and more companies use JIRA for task and requirement management within the (agile) software development. Meanwhile, meanwhile, evil tongues are not wrong to claim that JIRA is the new Excel, i. e. a tool with the company trying to kill as much as possible.
With regard to requirements management and other requirements engineering tasks, the question arises justifiably as to what benefits JIRA can provide in this environment. JIRA offers basic features for requirements management and can therefore keep up with explicit requirements management tools (RM tools) in many aspects. However, more and more companies are discovering that the use of JIRA (or similar tools) does not automatically lead to project success or that communication between the department and IT can only be improved to a limited extent. If there is no sufficient methodological basis for the project participants, the old saying “A fool with a tool is still a fool” or the even more drastic insight “Shit in, shit out”is also used in this context.
Without a doubt, JIRA offers excellent opportunities for task management and status control before, during and after development. But to know which tasks have to be done (that is, which requirements require implementation in a certain sprint or release) takes more than that. Good requirements engineering still includes core issues such as
- Who are my stakeholders?
- What are their needs?
- Which system properties and capabilities (requirements) result from this?
- How important are these requirements in each case?
- What is the relationship between the requirements and what kind of refinement is there between them?
- Have we forgotten important requirements or have we not specified them sufficiently?
- etc.
Established tools on the market can hardly, if at all, answer this question. The benefit of JIRA, but also other well-known RM tools in terms of the quality of the requirements, therefore still depends solely on the individual expertise of individual project participants.
The Requirements Management Tool “ReqSuite®”
With OSSENO’s ReqSuite® (see Fig. 1) a tool for requirements management has been presented in the past few years, which also supports content-related and methodological questions and can ensure the quality and completeness of requirements from the outset by means of intelligent assistance functions. Similar to a program for the preparation of income tax returns that helps inexperienced individuals to create accurate and complete standardized tax returns, ReqSuite® offers concepts to develop (sufficiently) good requirements documents in a standardized manner, regardless of personal expertise in the field of requirements engineering. The ReqSuite® Assistant also offers assistance in answering the above-mentioned core questions and points out incompleteness or inconsistencies directly during the documentation of requirements. The phrase “A fool with a tool is still a fool” therefore has only limited effect in this context.
The advantages are obvious and have already been confirmed by a large number of customers: ambiguities and incompleteness leading to costly rework before, during or even after development are proactively reduced. At the same time, there is always an overview of aspects that are not yet sufficiently clarified, which is crucial for success (unless they are developed in a waterfall-like way), especially when determining parallel to the analysis of running sprints. Finally, ReqSuite® automates formulations and formatting so that users can focus on the content of requirements rather than their syntax. This not only creates more freedom for thematic work, but also increases the acceptance of requirements engineering as a whole, which is often perceived as heavy and antiquated.
But should you now switch off your established JIRA and only work with ReqSuite®? Clearly no! Even if the correct answer always has to be answered in individual cases, it can be said that JIRA offers a large number of valuable features for many steps in software development that ReqSuite® has not yet been able to adequately replace. Nevertheless, ReqSuite® offers enormous added value for requirements engineering and similar disciplines, which JIRA and its extensions and accompanying tools such as Confluence cannot sufficiently achieve.
Accordingly, it is promising to highlight the joint and integrated use of JIRA and ReqSuite® in the following.
Methodical Integration
The methodical integration of JIRA with ReqSuite® is highly dependent on the business and development context. This concerns on the one hand the subject of development (e. g. the further development of an existing system in an insurance company vs. the development of a tax module in mechanical engineering) and on the other hand the scope of development activities (e. g. project vs. portfolio).
Nevertheless, the following best practice can be postulated for integration:
“ReqSuite® manages the content (including requirements) and JIRA manages the tasks within a portfolio or project.”
According to this best practice, it makes little sense to copy the contents of ReqSuite® from JIRA to JIRA one-to-one and create a redundancy in both tools. Rather, an abstraction level of content should be defined, which can be used as a suitable starting point for synchronization.
The main challenge in methodological integration (but also in general in defining a clean methodological approach) is therefore to define the refinement structure of content from requirements to the level of development activities. As a rule, there is no general model for this, since this structure depends to a large extent on the object of development. In the environment of an enterprise information system, this structure could, for example, contain requirements with regard to business processes, organizational units, use cases, system functions, business data and interfaces, which would have to be appropriately mapped to corresponding development activities (see also our WhitePaper on the definition of customized requirement processes).
Therefore, only an abstract refinement structure can be shown for the purpose of this article, which represents a possible division between ReqSuite® and JIRA (see Fig. 2).
In accordance with this model, ReqSuite® includes information about stakeholders, their context, their needs and the resulting topics, projects and requirements. In addition, JIRA maintains the development activities resulting from the requirements. Projects and project participants can be maintained redundantly in both tools.
If stakeholder requirements are now reported, they are specified in ReqSuite® in the form of topic descriptions within a corresponding portfolio. After appropriate examination and prioritisation of the topics, portfolio or programme managers can then map them to specific projects. Within projects, ReqSuite® then offers the abovementioned assistance functions to provide appropriate support to the project participants in gradually and quality-assured elaboration of the project requirements, taking into account the context.
At any time, but also at defined points in time, automated development activities (tickets) can be derived on the basis of requirements and exported to the associated JIRA project. If configured, an automatic assignment to the project participants responsible for the conversion can also be carried out. Once you have completed your tasks, you can then update the status of your activities, which is then automatically reflected back to ReqSuite during the next synchronization, thus documenting the fulfillment status of the requests.
An important question at this point, however, remains how individual (system) requirements can be mapped to development requirements for the respective development activities. This also depends on the development context. In the above example, it would be conceivable to gradually break down business requirements over different abstraction levels such as business processes and use cases to the level of fine-grained system functions, which also represent the content of individual development requirements. For example, the request “As a life insurance administrator, I would like to see the surrender value of a contract on the contract overview, so that I can inform the customer more quickly”. from ReqSuite® as a development requirement (ticket) in JIRA and the resulting development activities are implicitly visible to the developers. Alternatively, however, it would also be possible to further refine the requirement in actual activity descriptions such as “Extension of mask LV-1 by a read-only field surrender value”. The latter would have the disadvantage of increased specification efforts, but the advantage of a more precise task description and a finer granular tracking.
Technical Integration
One of the main arguments, which is sometimes used against the use of several tools, is integration and consistency problems. If data can only be exchanged manually or only partially automated between different tools, this is not only a hindrance to efficiency, but also an enormous source of error. In addition to methodical aspects of integration, the technical integration capability also plays a decisive role. The technical integration of JIRA and ReqSuite® has therefore been designed to be multi-stage, dynamic and bi-directional.
Multi-level integration
At the top level of integration, projects in ReqSuite® are linked to corresponding projects in JIRA in the form of a 0.0… 1 relationship. For each project in ReqSuite®, max. a project can be stored in JIRA. Conversely, several ReqSuite® projects can synchronize content with a JIRA project. The reason for this asymmetrical relationship is that ReqSuite® wants to define a clear “buyer” for the requirements. Conversely, however, a JIRA project can consolidate content from different ReqSuite® projects, as the customisation within the development process may be organized differently than at the technical project level within the topic portfolio. Fig. 3 shows, for example, that the “IT requirements” project from ReqSuite® is to be synchronized with the “ReConf2017” project.
At the second level of integration, the requirement types from ReqSuite® are linked to issue types in JIRA in the form of a 0.0… 1 relationship. In each project, you can define whether the requirements of a certain type of ReqSuite® should be exported to JIRA and, if so, which issue type. In the above example, you could specify that only requirements of type “Function” should be synchronized with JIRA (see Fig. 3) in the form of issue type “Task” (see Fig. 4).
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 also set very individually how individual fields from ReqSuite® are related to JIRA fields. The project participants can also be mapped automatically, so that the assignees responsible for implementation can be defined in JIRA in ReqSuite®.
Dynamic Integration
When integrating ReqSuite® with JIRA, great importance was attached to flexibility and configurability. Consequently, the interface was developed in such a way that hardly any static mappings were predefined, but can be completely selected 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. This means that it is also possible to include custom types and custom attributes, i. e. self-defined types and fields, in the mapping.
Bidirectional Integration
Bidirectional integration means the possibility of not only transferring content from ReqSuite® to JIRA, but also reflecting it back as required. When configuring the interface, you can therefore define whether a (bidirectional) synchronization or only a (unidirectional) export of ReqSuite® to JIRA is required. In the case of a real synchronization, the interface is able to merge changes on both sides or, in the case of a conflict, to resolve them automatically on the basis of stored rules. This virtually eliminates friction losses due to inconsistencies.
When does Integration make Sense?
The integration of JIRA and ReqSuite® can bring many advantages for requirements engineering and management. In concrete terms, the use of ReqSuite® in addition to JIRA makes sense, especially in the following cases.
If quality or completeness of requirements are inadequate
If the quality, completeness or standardization of requirements is not satisfactory, ReqSuite® offers excellent possibilities to remedy this. This is often (but not only) the case when technically less experienced colleagues from specialist areas are involved who have little experience with writing good requirements. Having them write their wishes and requirements directly in JIRA or upstream tools such as Confluence without assistance, usually brings with it a lot of advantages. and costly clarifications and adjustments are unavoidable.
If documents are needed in addition to tickets
In many organizations, various documents are needed for project work, even if the project is to be developed in an agile way. By separating content and representation more neatly in ReqSuite®, ReqSuite® can automatically generate all required documents and reports such as project applications, technical concepts, IT concepts, acceptance concepts, offers, etc. in the desired corporate design at the push of a button. JIRA is very limited in terms of the generation of such documents.
If a good cooperation between business and IT is desired
If a good cooperation between the department and IT is desired, a clear separation of content descriptions and development-relevant tasks makes sense. In particular, it is necessary to address the language of the departments appropriately (think, for example, of processes, tasks and documents) and to abstract from technical details or concepts. A further advantage of the separation of content and development task is that concrete development tasks, which are usually not only restricted to the development of the content, but also to the content and development task, can be carried out. only have to be carried out once in the context of a concrete project, can be clearly separated from the content implemented therein, which may be repeated across projects (e. g. data glossaries).
If project participants cannot or do not want to work with JIRA
Even though JIRA is quite easy to use, it is still a developer-to-developer tool for developers and not a tool where department staff feel at home. Especially when it is unclear what the requirements are and how they can be derived systematically, it is not enough to define simple templates for Epics and user stories, for example, to determine the needs of the departments appropriately. Here it makes sense to support the respective work by means of target-group-specific entry masks and assistance functions. While this is a time-consuming and costly process to implement in JIRA, ReqSuite® comes with simple yet powerful features.
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 is desirable, especially in the case of cross-departmental cooperation, especially on the part of the departments. Much sought-after products, which are often advertised in a bundle with JIRA, do not offer any real work assistance for project participants and often do not represent more than a web-based Word alternative; with all the advantages and disadvantages known from working with Office products up to now. To the extent that the above-mentioned aspects exist, additional use of ReqSuite® as a comprehensive and, above all, content-focused portfolio and requirement tool should therefore be considered.
