Requirements Engineering Blog
A method for flexible, tailor-made requirements processes
Abstract
Recent studies show that many companies are still struggling to carry out efficient and effective activities in the field of requirements engineering. Company-specific, tailor-made requirements processes have great potential to meet this challenge. This paper describes a novel approach that enables the semiautomatic definition of company-specific requirements processes and the use of tools to achieve a more sustainable and, above all, more valuable implementation of this discipline.
Introduction
The RE Compass 2014 / 2015 [1] has shown that a large number of companies are still confronted with fundamental questions in the field of requirements engineering, such as:
- What level of detail of requirements is appropriate/necessary? (69% of the companies surveyed)
- What types of requirements must be collected? (37% of the companies surveyed)
- How can the requirements be collected and documented in a meaningful way? (35% of the companies surveyed)
These ambiguities lead to ambiguous and incomplete specifications in almost half of the companies, with correspondingly negative consequences within the projects[1].
Although existing literature and training [2][3][4][4] offers good best practices for the collection and documentation of requirements, the above-mentioned questions can often only be answered in a context- or company-specific manner. This results in a high potential for tailor-made requirements processes to ensure an effective and efficient mode of operation during the requirements assessment and documentation in the respective company environment.
However, companies face numerous other challenges in implementing and successfully implementing such individual processes, such as the
- Defining a meaningful elicitation order for requirements,
- Easy feasibility of the elicitation and documentation tasks by the project participants (particularly for those involved without in-depth expertise and experience in requirements engineering)
- Relief of purely administrative, non-value-adding activities in requirements engineering, such as linking requirements,
- Mapping of defined procedures into tools for requirements engineering without sacrificing flexibility.
Especially with regard to the last point, it is worth mentioning that standard office applications such as MS Office® are still used for requirements documentation in around 80% of all companies[1]. On the one hand, these products are popular because they are well known and widespread and offer a simple, familiar use. On the other hand, the use of such standard software often pushes you to the limits when it comes to making work steps during requirements assessment and documentation more efficient. If these products are not to be completely replaced, this must also be taken into account when tailoring requirement processes.
This article introduces a tool-based approach that optimizes the introduction and execution of bespoke requirements processes in companies. The aim of this approach is to be able to carry out company-specific requirements processes effectively and efficiently, but also to address the special challenges arising from this during the introduction in a targeted manner. The innovative tool “ReqSuite®” is used for this purpose, with the help of which individual requirement processes can be mapped conceptually and processed with the help of common office software.
A tool-supported methodology for the introduction and implementation of flexible, tailor-made requirements processes
The method for the tool-supported introduction of customized requirements processes consists of a total of four steps (see Figure 1), which are explained in more detail below. It should be noted that the first three steps are one-time steps for setting up a requirements process and therefore usually only have to be run through once. Step 4, on the other hand, is carried out several times, i. e. once per project.
Step 1 – Determine information and documentation requirements: In a workshop, the individual information requirements in typical RE projects are first determined together with the RE participants of the company. These could be, for example, specific requirements types, domain-specific requirements structures, and other information that should be contained in the requirements documents. To do this, the current RE process is first analyzed. This can be realized in the workshop, for example, by means of map queries in which all participants present their activities as well as the required and delivered information during the creation of the requirement specification. Interfaces to downstream processes such as change and test management can also be identified and analyzed. In addition, existing requirements documents are considered in order to identify further information requirements. In addition to content, the study also looks at description templates and notations that have become established in corporate practice or which could be usefully used in the company in the future. In order to optimize the entire requirements process, expert knowledge and established best practices from the literature are included in addition to any suggestions for improvement made by the company’s stakeholders.
Step 2 – Derive Requirement Structure: In the next step, the analysis results are documented using a domain-specific language. In the first step, the structure of the requirements types and accompanying information is mapped. For example, you can define that system functions are always used in application cases that support business process activities in business processes (see figure 2).
The mapping of this structure is not only important and useful for ensuring the traceability of the requirements, but also provides a decisive basis for subsequent process support (see step 4). This model thus forms the logical “thinking model”, which stands behind the requirements process and which has to be filled with content within the framework of a concrete project.
Based on the results from step 1, you then define for each requirements type or information module how the documentation of the corresponding requirements or information is to be carried out within the framework of a project. Among other things, it is determined whether the description is to be textual (e. g. by means of certain natural language typesetting templates) or graphical (e. g. by means of UML models) and which attributes (e. g. priority) are to be maintained for the different requirement or other content types. In the example in Figure 2, for the requirements type “business process”, for example, it could be defined that each process to be described in the requirement specification can be described using a graphical process description, such as BPMN, and is also to be specified by means of a short tabular description using various attributes.
The formalized description is imported into the ReqSuite® tool and automatically transformed into an adaptive requirements workflow. In addition, a company-specific template of the requirement document is stored in the tool, into which the actual requirements and contents can be exported later at the push of a button. The user can specify, for example, which content from the database should appear in the document in which form. Due to this strict separation of content and representation, requirements can be recorded and documented differently than they are ultimately represented in the requirements document. Accordingly, several templates can be stored if, for example, different documents are to be created from the data at a later date (e. g. a requirement specification and a test specification).
Step 3 – Importing existing requirements: In many companies, systems are not developed from scratch, but are continuously being expanded and enhanced with new functions. This is also reflected in the corresponding requirement process, as requirements from old projects can or even have to be reused. This pool of existing requirements should be used to create an explicit reuse basis for future projects in order to increase efficiency, in order to avoid the risks of a clone-&-down approach. Relevant requirements from old projects are identified by examining old requirement documents, for example. The requirements should be checked for up-to-dateness so that no obsolete requirements are adopted. Because building a reusable base is very time-consuming, ReqSuite® can be used in this step to automatically import requirements from Word or Excel documents into a central reusable library in an appropriate form.
Step 4 – Execute Requirements Engineering Process: The actual execution of the requirements process is based on work steps that are dynamically defined at runtime and provided to users by the ReqSuite® tool. Unlike conventional requirements management tools [5], ReqSuite®, which is integrated into Microsoft Office® products on the client side (see Figure 3), supports not only the specification and management of requirements, but also the entire process of elaborating requirements in terms of content.
The algorithms of ReqSuite® are based on expert knowledge and are able to propose a sensible sequence for the elaboration of the relevant requirements. At runtime, the tool generates a set of precise work instructions for each process step in the so-called Process Guide (see lower part of Figure 3) in order to guide the project participants step-by-step through the individual elicitation and documentation tasks. Comparable to programs for preparing tax returns, the tool ensures that the resulting requirements contain complete content in the desired form by continuously querying and quality checking the desired information.
The process is not static, but the tool always acts adaptively throughout the entire application, which means that a sequence of work steps does not have to be defined in advance or followed exactly. Instead, the work steps are adapted at runtime on the basis of the requirements already established. This takes into account the fact that, due to the fast-moving nature of projects, processes of requirements cannot be formalized in the form of rigid processes anyway, but seldom correspond to the desired procedure of the project participants in the requirements analysis.
The agents can therefore ignore the recommended steps at any time and carry out other processing operations independently. For this purpose, ReqSuite® provides the so-called Content Manager (see right-hand part of Figure 3), in which the requirements, as well as other information content and its relationships can be created and maintained. However, the tool always suggests the most sensible next step – based on the known options for further procedure and taking into account any limitations.
This process support helps in particular also project participants without relevant expertise in requirements engineering to contribute to the creation of requirement documents in a purposeful way. A project progress display always shows the current status of the requirements elaboration.
The details for requirements are entered directly in Microsoft Office® or via pop-ups provided by ReqSuite®, which are based on the previously stored configuration for the respective requirement type. In each step, the individual requirements and entire requirement structures can also be imported from other projects or from the reuse base in order to considerably speed up the use of existing documentation.
Practical Experience
Especially for companies that often deal with special topics or outside RE standards in their project business, a high degree of individuality in their requirements processes is crucial for achieving acceptance of requirements engineering by both their own employees and the customer.
The high adaptability of the approach described here, coupled with its systematic guidance for pilot customers from various industries, has already enabled more efficient project work.
This was due in particular to the fact that the individually configured tool enabled requirements to be collected and documented in a more complete and consistent manner, which meant that fewer queries were necessary due to incomplete or unclear requirements. In particular, employees who had little practical experience in requirements engineering to date could benefit from the approach to improve their own tasks by focusing on essential aspects of content. This is a significant support for companies, as requirements are often collected and documented using very different approaches in practice – depending on the framework conditions and the availability of stakeholders.
At HK Business Solutions, for example, it was shown that even inexperienced employees can be systematically supported in a structured procedure with a top-down approach by means of adaptive process instructions. This begins with activities that have to be settled very early in the development process, e. g. the creation of product visions and the definition of system context and scope, and ends with the consistency and completeness check of all created requirement artifacts. Many errors that typically arise due to incomplete, misleading or incorrect requirements can be avoided by this support and the systematic re-use of requirements that have already been recorded and quality-assured.
Measurable value of the approach is therefore a higher completeness, quality and uniformity of requirement documents and a consequent saving of effort in the overall project or in maintenance and support costs. This is a significant added value in that, according to RE-Kompass [1] incompleteness and inconsistent level of detail in 48% and 69% of all companies, respectively, represent the greatest shortcomings of requirements documents at present.
Even though the effort for the requirements process can hardly be reduced due to the structured approach, all users confirm that their tasks in the requirements analysis could be simplified and accelerated considerably. The introduction of the new RE approach is facilitated by the fact that the approach is based on familiar standard office software, which made it easy to roll out and allowed users to quickly find their way around. Successive management through various steps of the process also helps to better internalize the individual corporate approach in requirements engineering.
Conclusion
Tailor-made requirements processes are indispensable for successfully embedding the topic of requirements engineering in companies. However, defining and implementing such business processes is an additional challenge for many companies. This article therefore proposes a novel, tool-supported approach to support bespoke tailoring and subsequent application of individual requirements processes.
References
- Adam, S., Wünch, C., Seyff, N.: RE-Kompass 2014/2015 – Ergebnisbericht, http://www.re-kompass.de
- Pohl, K., Rupp, C.: Basiswissen Requirements Engineering, dpunkt (2011)
- Rupp, C.: Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil, Carl Hanser (2014)
- Wiegers, K., Beatty, J.: Software Requirements, Pearson Education (2013)
- Birk, A., Heller, G.: List of Requirements Management Tools, http://makingofsoftware.com/ re-sources/list-of-rm-tools
Authors
Dr. Norman Riegel is Managing Director of OSSENO Software GmbH and is primarily responsible for consulting, quality assurance and administration. He is an IREB-certified Requirements Engineer and works as a trainer for CPRE. Prior to founding OSSENO Software GmbH, he worked as a consultant, trainer and scientist for requirements engineering at Fraunhofer IESE. Parallel to his work, he also earned his doctorate at the Technical University of Kaiserslautern on the subject of “Efficient requirements assessment based on business processes”.
Dr. Sebastian Adam is Managing Director of OSSENO Software GmbH and is responsible for product innovation, marketing and sales. He is an IREB-certified Requirements Engineer and works as a trainer for CPRE. After his studies in Applied Computer Science, he worked for ten years as a consultant, scientist and team leader for Requirements Engineering at Fraunhofer IESE and at the same time did his doctorate at the University of Kaiserslautern on the topic of “Reusable Requirements Survey”.
Hartmut Schmitt is coordinator of research projects at HK Business Solutions GmbH. Since 2006 he has been working in collaborative projects in the fields of human-computer interaction, usability, user experience and requirements engineering.
