Dr. Sebastian Adam Norman Riegel Dr. Joerg Doerr

TORE

A Framework for Systematic Requirements Development in Information Systems.

When engineering requirements, many requirements professionals are challenged not only by the question of how to elicit or specify requirements, but additionally by knowing which requirements types they have to elaborate and describe, and to what degree of detail, in order to achieve a consistent and complete specification. To provide a solution to this challenge, a mental model is needed that may serve to guide practitioners conceptually during a requirements engineering process. In this paper, we introduce the task-oriented requirements engineering framework (TORE) which aims to provide such guidance. Experience from practical application highlights its benefits and limitations when using it in industrial scale software development projects.

Why Techniques are not sufficient

When engineering requirements, requirements professionals in industry are faced not only by the challenge of HOW to elicit requirements or HOW to document them appropriately, but also by the challenge of knowing WHICH requirements have to be elicited, in WHICH logical order, to WHAT degree of detail and by involving WHICH stakeholders. In many cases, requirements are therefore elicited without proper guidance leading either to incomplete documents, or at least unfocussed and inefficient elicitation cycles in which one gets lost in details.

Asking for Tools and Techniques as Symptoms

Often, initial questions of industrial partners concerning tools or techniques to be used turn out to show the more fundamental issue of an absent mental model of requirements. E.g., the statements of industrial partners that a certain technique does not work in their context is often due to the fact that they use the same technique to document different requirements types, even those for which the technique was not intended. This, in the end, reduces the overall requirement engineering (RE) efficiency.

Thus, the traditional approach of just eliciting software requirements has been experienced as not being sufficient for providing adequate stakeholder support and fulfilling certain goals related to a software system ^[1]. In particular, the efficient development of complete and correct requirements specifications is difficult if the purpose and the application context are not explicitly considered.

The Need for Mental Models and a Conceptual Decision Framework – Goal- and Task-orientation as Starting Point

When analyzing the reasons for this problem in the past, we observed a lack of, or at least a low, popularity of mental models that may serve to guide people in systematic requirements development and refinement processes. In particular, RE literature and fundamental RE education had put their focus on techniques and methods for different RE activities only, while neglecting holistic models that may span the whole RE process. In 2002, researchers at the Fraunhofer Institute for Experimental Software Engineering (IESE) therefore started developing a conceptual decision framework (called TORE – task-oriented requirements engineering) that expresses all important decisions people have to make during a typical RE process. By making these decisions explicit and by explaining their mutual influence, this framework is able to guide practitioners by providing a model that can be applied systematically when evolving requirements.

When this is done, there has been a shift towards a stronger orientation towards the tasks of users and their goals to be supported. Several state-of-the-art requirements engineering approaches such as goal modeling ^[2], scenarios ^[3], or Use Cases ^[4] reflected this orientation towards problem-oriented rather than solution-oriented requirements at the beginning of each development project. Thus, the application environment and domain requirements, i.e., the business tasks and goals to be supported, were to be analyzed first in order to make the actual product requirements, and thus the resulting systems, more usable and appropriate for their intended purpose and audience.

Integration of the Business Perspective

Influenced by the goal- and task-orientation paradigm, the TORE framework initially aimed at Usability and Human Computer Interface (HCI) issues and a stronger consideration of the corresponding principles in requirements engineering. With a growing maturity of this framework ^[7] and systems becoming more and more complex, the TORE framework has been continuously adapted in recent years towards a comprehensive instrument for guiding requirements development in business information systems. Topics from business informatics, such as business process management and optimization, have also found their way into the framework. The framework is based on the observation that systems probably will not support the users and organizations in an adequate manner if the more application-oriented decisions on a high level of abstraction have not all been made before lower-level requirements decisions are addressed.

Furthermore, conceptual dependencies among decisions influencing the business perspective, the user perspective and the technical perspective must be understood in order to achieve a holistic requirements engineering. Thus, TORE aims at making the conceptual dependencies between different decisions explicit, allowing better guidance during the entire requirements process, resulting in effective and efficient requirements engineering in practice.

TORE as a Framework in Practice

An invaluable repository of RE terminology and knowledge has been provided by the IREB training courses and certifications. Since the TORE framework does not prescribe any requirements practices or techniques, it is a valuable complement to the techniques provided by IREB, providing a mental model for the entire requirements engineering phase.

The TORE framework was successfully trained and applied in more than 20 organizations and used within several projects in industry, research, and also the public domain. We have found that orientation towards the decisions to be made during requirements engineering rather than towards certain artifacts, techniques, or processes enables a highly flexible application of the goal- and task-oriented paradigm with an integrated business perspective in different domains and project settings. Besides better guidance in the elaboration process, many organizations could also achieve improved documentation quality according to the IEEE (Institute of Electrical and Electronic Engineers) Standard 830 “IEEE Recommended Practice for Software Requirements Specifications” ^[10] criteria, as documents and their contents were better structured and focused.
In the remainder of this article, we will describe the TORE framework, possible ways of how to apply it, and the experience we have gathered so far.

The TORE Framework in a Nutshell

The TORE framework provides a mental model for people involved in a RE process without prescribing details as to exactly how the different process steps are carried out. Rather, the aim of the TORE framework is the clarification of the decisions to be made when elaborating the requirements for an interactive (or information) system. The underlying assumption of this framework is that each RE process is a decision process in which the stakeholders of a system determine the scope, functionality, quality, and usage context of a system.

Basically, “a decision is a choice made between alternatives in a situation of uncertainty” ^[8]. In the context of RE, a decision typically answers a guiding question in the style of “what do I want” and therefore determines the properties and capabilities of a (future) system.

It’s all about decision-making

In the TORE framework, the typical (and probably the most important) decisions (called “decision points”) to be made during a RE process are arranged on four different levels of abstraction:

• Project Level
• Business Level
• Interaction Level
• System Level.

Table 1 lists these decision points on the different levels including their guiding questions.

Level	Decision Point	Guiding Question
Project	Project Topic	What is the overall topic of the project?
	Stakeholders	Who are the stakeholders (e.g., departments, roles, persons, etc.) that are affected by the project?
	Project Goals	What goals is the project supposed to achieve? What should be the benefit at the end?
	Addressed Tasks & Processes	Which business processes and/or user tasks are to be analyzed and addressed in the context of the project?
Business	As-is (Process) Situation	How are the business processes and/or user tasks currently performed? What are their strengths and weaknesses?
	To-be (Process) Situation	How should the business processes and/or user tasks be performed in the future in order to be able to achieve the project goals?
	System Responsibilities	Which parts / steps of the to-be business processes and/or user tasks should be supported or even automated by the system to be developed?
	Business Data & Rules	Which data and rules are relevant in the considered business processes and/or user tasks?
Interaction	Interactions	How should users or external systems interact with the system to be developed for achieving the results of certain steps in the business processes and/or user tasks?
	System Functions	Which system functions are needed for realizing the system responsibilities or interactions?
	Interaction Data & Rules	Which data are exchanged in the interactions? Which interaction rules apply?
	Logical UI Structure	How should data and system functions be grouped logically within the user interface?
System	GUI Layout	How should the visual design of the user interface look like?
	Dialogs	How should the dialogs between user and system be designed? How do screen transitions take place?
	GUI Data	Which widgets should be used and which data should they represent?
	Specific GUI Functions	Which additional functions are needed to support the user’s navigation?
	System Architecture	How should the system be organized / structured internally?
	Internal Functions	How should the system functions be realized by means of methods, procedures, etc.?
	Internal Data	How should the business data be represented in the data storage?

The idea of the TORE framework is to make the presented decisions explicit in RE with the aim of achieving conscious decision-making among the stakeholders rather than letting these decision be made implicitly by developers afterwards (as it is still often done in practice). Hence, TORE tries to constructively assure that there is an early consensus for all important decisions.

However, not all decisions can be made by all stakeholders all the time, as this would lead to an ineffective, inefficient, and chaotic development of requirements. TORE addresses this problem by the clear definition of decision points and their arrangement on different levels of abstraction. Basically, the levels represent logical project phases indicating logical dependencies among different decisions. This means that, for instance, decisions on the business level depend on decisions of the upper project level and cannot or should not be made prior to finalization of the project-level decisions without good reasons.

The TORE framework does not prescribe a concrete RE process; rather it guides and supports requirements engineers logically. In particular, TORE supports completeness as it enables stakeholders to be aware of important decisions they have to make in order to avoid developers making these decisions unconsciously. Furthermore, TORE assists requirements professionals in focusing and assigning responsibilities for different RE tasks, as it is neither meaningful nor possible to clarify all details with all stakeholders at one point in time. Thus, by covering different decision points in different meetings, decisions can be made in a more targeted and efficient way. The appropriate techniques to document the individual decisions are selected and defined separately. Finally, TORE supports finding the right level of detail when discussing a certain decision point. For instance, when discussing system responsibilities according to its guiding question, it is clear that the representation of any data on the user interface is not topic of this discussion. Hence, TORE assists people in a RE process by ensuring that the wrong issues or issues on a wrong level of granularity aren’t being addressed.

Regarding this support, the four levels of abstraction are of special importance. As depicted in Figure 1, the project level aims at shaping the project scope by clarifying the project topic, identifying the relevant stakeholders, elaborating their goals and defining the tasks and processes to be addressed (and probably improved) in the project. On this level of abstraction, business people and domain experts are usually the right group of people to involve, as there is still no relationship to the software system to be built.

The business level then aims at investigating the current situation in the selected tasks and processes, and at defining a to-be situation. Furthermore, the desired system support is determined and the affected business data and rules are described. On this level of abstraction business people, end users, and IT innovators should participate, because these decisions will significantly change their daily way of working.

On the interaction level, decisions regarding the interface between the system to be built and its environment are discussed. Besides a determination of how users and external systems should interact with the system (including the exchanged data), and which system functions are required for that, a logical model for the user interface is developed. Since these decisions strongly affect both the system design and the system usage, end users, business experts and development engineers, as well as architects and user interface designers, should work collaboratively here.

On the system level, decisions regarding the concrete design of the user interface and the internal implementation are made. Even though these decision points also result in requirements, the business side should not make these decisions; such decisions require an in-depth knowledge of the technology or user experience. However, stakeholders should validate the decisions, of course, at least those regarding the look and feel of the user interface. To avoid doubt, we want to clarify that we see the system's GUI-related decision points as requirements-relevant decisions, i.e., decisions on these decision points must be validated with the project stakeholders. The decision points on the system’s application core are requirements-related, but they are decisions on the architecture and design level and impact requirements.

Bringing the Framework on the Road

As noted previously, the TORE framework does not prescribe a particular RE process. Thus, the framework can be used in agile as well as traditional waterfall-like projects. However, there are dependencies among the decision points that define a logical elicitation sequence that should not be violated. Our experience shows that otherwise a high amount of effort is spent compensating for the missing links late in the project. Figure 2 shows the logical sequence when discussing the decision points on the project, business and interaction levels.

At the beginning of each project, the project topic has to be defined first. Even though many people assume that this is straight-forward, experience shows that different stakeholders have different expectations about what the project should be and what should be within and outside the project scope. However, a clear understanding of the project topic is also needed for identifying the relevant stakeholders. If one does not know what the project should be about, it is likely that he / she cannot identify the affected stakeholders systematically. The same holds true for the elaboration of the project goals and the identification of the tasks and business processes to be addressed in the project. Firstly, without having identified and invited the relevant stakeholders (or at least representatives), it is not possible to elicit the project goals in a reliable manner. Secondly, without having defined the goals to be achieved, it is impossible to fully identify the tasks and processes to be addressed further.

On the business and interaction level, this pattern continues. The as-is (process) situation can, of course, only be analyzed when it is clear for which tasks and business processes that should be done. The to-be (process) situation can, ideally, only be elaborated in a structured way, if the corresponding as-is situation has been understood before. And, of course, the system responsibilities and relevant business data for the system to be built can be determined only after the to-be process is defined, as otherwise one would tend to establish the “old” as-is process in a new system, typically not leading to an optimal solution. Furthermore, without having defined the system responsibilities (i.e., the steps in the processes to be supported or even automated by the system), it is not possible to define corresponding interactions and system functions, or the interaction data and logical screens that they require.

Thus, even though TORE does not prescribe a process, there is a logical sequence that has to be taken into account when developing requirements for an interactive system. Below, three examples of how to apply this logical sequence in real RE processes are provided:

• When doing RE in a waterfall manner, the actual RE process would exactly run as depicted before. For instance, interactions would not be defined before all system responsibilities for all tasks and processes to be addressed are completely elaborated. Even though this process is rather easy to perform, a strong disadvantage is that the larger the project the later the development can start. Furthermore, this approach is very inflexible in case of changes.
• When doing RE in a parallelized manner, the actual RE process would also run as depicted before, but for each element of the application domain more or less independently. For instance, when having determined all tasks and processes to be discussed on the project level, the refinement of these tasks and processes down to system functions, etc. could be done independently in parallel. However, a disadvantage or risk in this case could be the consolidation at the end, as well as the fact that the finalization of the requirements document depends on the slowest branch.
• When doing RE in an incremental manner, the actual RE process would run as in the parallelized way with the difference that each increment would write its own requirements document and release it to development. Hence, a consolidation of the different increments would not take place. Thus, besides specifying the increments in parallel, they could also be specified subsequently.

Beyond these traditional approaches, TORE is also applicable in agile environments. Basically, there are different ways for how to apply TORE there. One possible approach is to fill the product backlog with user stories written for the decision point “system responsibilities”. In this case, the previous decisions have to be made in an upfront “sprint zero”, while the subsequent decisions have to be made in each individual development sprint. Another possible approach for agile development is to separate the development sprints from analysis sprints explicitly, so that the analysis sprints work according to the incremental approach described before, and hand over the elaborated requirements incrementally to the product backlog. Be advised that TORE in agile development is still not completely researched and there remain some interesting research questions to be resolved.

TORE in Industry: An Example of how to Deploy the Framework

The TORE framework has been applied in numerous contexts during the last decade:

• Teaching requirements engineering at universities,
• Teaching in industry training courses,
• During the application of requirements engineering in industry and with public authorities, and
• During the application of requirements engineering in large national and international research projects.

As a framework for business information systems, it has been applied in several industries and domains, for example finance and insurance, e-commerce and web applications, public and e-government as well as the logistics, chemical, and medical domains. It is used in small and medium-sized enterprises with small and local development projects as well as in large enterprises with huge development projects involving distributed international teams.

In the following section, we will describe a case study where TORE was applied during a time-critical project with distributed international teams in one of our customer organizations, a large international medical enterprise. The product to be developed was a large information system. Based on an earlier project with Fraunhofer IESE, the enterprise recognized a need for a more structured, state-of-the-art requirements engineering process. Thus we were asked to apply TORE in the project in order to enable the organization to have their first experience with it.

In order to adapt TORE to the organization and project-specific conditions, an initial assessment of the current requirements engineering process was first carried out. The assessment revealed several severe shortcomings. Important decision points prescribed by TORE (e.g., to-be process situation, system responsibilities, business data, as well as interactions) were missing completely, while other decision points were not addressed in sufficient detail leading to large gaps and severe traceability problems. Thus it was decided to conduct TORE training with all project members in order to revise the existing requirements information (as the project was already started) and enable project staff to fill the remaining gaps with sensible requirements information. An important aspect of this training was the conveyance of the mental model of TORE in order to enable project staff to think about the requirements in terms of decision points and on different abstraction layers. The training was further customized to the particular project situation, i.e. for each TORE decision point, techniques were defined for eliciting and specifying the different requirement types. This is essential as TORE does not substitute techniques, it complements techniques. Thereby the time criticality and the international distribution of the stakeholders were taken into account, resulting in a lean specification style and “user-friendly” notations for the stakeholders’ own documentation without the need for requirements specialists. For example, system responsibilities in the business processes were described by using a set of sentence patterns, making the anticipated benefits of the system in the workflow directly visible without exhaustive specification effort. Furthermore, it was decided to use exercises during the training to revise existing or create new content for the requirements specification. Thus, the benefits of TORE were directly visible in the project and for the project members.

After the training, the participants had gained a good understanding of TORE while at the same time producing valuable results for the project. Subsequently, the project staff has been able to create the various demanded specification artifacts themselves with only minor coaching. A conclusive review showed the high quality of the requirements specification, despite it being created under high time pressure. The easy concept of TORE had enabled the project staff to elaborate a good specification within the minimum time, despite an initial lack of knowledge of requirements engineering concepts.

General Benefits and Limitations

The case study described above is a typical example of the application of TORE in industry. Based on our long term experience with TORE we have identified the following general benefits of using TORE:

Support for systematic thinking without prescribed processes and notations. By focusing on decisions, TORE becomes widely applicable in different domains and also in different development settings. The decision points serve as the rationale to explain why specific requirements activities and artifacts are needed. Furthermore, stakeholders can discuss which decision points need to be documented explicitly in the specification and which will be kept implicit.

Increased understanding of the domain. Understanding the processes and tasks to be supported, as well as current problems, makes it easier to detect improvement potential.

Systematic functional decomposition and completeness. Starting from a system-independent view on project and business level, more consistent and complete requirements specifications can be achieved, in particular as the decision points are explicitly linkable using appropriate notations. For instance, each system function can be recursively traced back to the business process and activities from which it is derived.

Separation of concerns. By making abstraction levels and their dependencies explicit, TORE allows abstraction from system issues, which also allows the definition for hybrid hardware and software systems. Furthermore, it helps to determine the appropriate requirements abstraction level needed for the requirements specification.

A Prerequisite for effective prioritization. The decision points in TORE can serve as natural candidates for making prioritization decisions. After eliciting information for a decision point, prioritizing alternatives or scaling down the system scope are typical decisions to be taken. By using the TORE framework, one can decide at which decision points prioritization should take place.

Integration of business process management and usability aspects. Due to the focus on business processes and user tasks, requirements engineering can be aligned more closely to business process management, therefore avoiding redundant work. By connecting usability decisions with requirements decisions during the requirements phase, User Interface (UI) development can be better integrated with requirements.

Support for RE education and technology transfer. Through its intuitive structure, it is a good means to familiarize novices with the concepts of requirements engineering in a short timeframe. The decision model is a good means to discuss as a first step what concepts in RE are really needed. Process and artifact/notation definitions may follow in a second step.

However, there are still some limitations of TORE to be resolved in future work.

Remaining abstract. As the decision points are more abstract than process activities or notations, corresponding requirements techniques still have to be determined, which requires expert involvement and consultancy. In our opinion, the IREB curriculum matches well to the TORE framework in that it presents many relevant techniques and notations.

Limited to functionality. Non-functional requirements ^[11] other than usability are not (yet) reflected and have to be handled separately, e.g. by means of a framework to elicit non-functional requirements ^[9]. Thus, TORE does not provide a full-fledged approach yet.

Limited to interactive (workflow) systems. Systems that do not deal with any kind of interaction (e.g., embedded systems) are not addressed sufficiently by TORE decision points. For such systems, other decision points may be more applicable.

Conclusion

When engineering requirements, many requirements professionals are challenged not only by the question of how to elicit or specify requirements, but additionally by knowing which requirements types they have to elaborate and describe and to which degree of detail in order to achieve a consistent and complete specification. To provide a solution to this challenge, a mental model is needed that may serve to guide practitioners conceptually during a requirements engineering process. In this paper, we have introduced the TORE framework which aims to provide such guidance. This framework proposes 16 RE-related decision points, which may act as guiding questions during requirements development activities.

Based on our overall successful experience with TORE, we are convinced that it provides excellent support for very different kinds of interactive systems. Especially the abstraction from concrete notations and processes has been found to be a good basis for systematic and practical requirements engineering. Due to its application in industry and the resulting operational feedback, as well as our ongoing requirements engineering research, TORE is continuously being enhanced to cover the requirements engineering needs of new areas of information system development.

References

• [1] S. Lauesen, Software Requirements – Styles and Techniques, Addison-Wesley, 2002.
• [2] A. v. Lamsweerde, “Goal-oriented requirements engineering: a roundtrip from research to practice”, Proceedings of 12th IEEE International Requirements Engineering Conference, IEEE, 2004.
• [3] N. Maiden, S. Minocha, K. Manning, M. Ryan, “REWS-SAVRE: Systematic Scenario Generation and Use” Proceedings of IEEE International Requirements Engineering Conference, IEEE, 1998.
• [4] A. Cockburn, Writing Effective Use Cases, Addison-Wesley, 2000
• [5] Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
• [6] B. Paech, K. Kohler, “Task-driven Requirements in Object-oriented Development”, Perspectives on Software Engineering, Kluwer Academic Publishers, 2004.
• [7] S. Adam, J. Doerr, M. Eisenbarth, A. Groß: Using Task-oriented Requirements Engineering in Different Domains - Experiences with Application in Research and Industry, In: IEEE Computer Society: 17th IEEE International Requirements Engineering Conference. RE 2009 - Proceedings. Los Alamitos: IEEE Computer Society, 2009, 267-272.
• [8] Business Dictionary. http://www.businessdictionary.com, last visited: 2014-08-01.
• [9] J. Doerr, Elicitation of a Complete Set of Non-Functional Requirements Stuttgart: Fraunhofer Verlag, 2011. (PhD Theses in Experimental Software Engineering; Vol. 34). (Zugl.: Kaiserslautern, Techn. Univ., Diss., 2010). - ISBN 978-3-8396-0261-4.
• [10] IEEE, IEEE Recommended Practice for Software Requirements Specifications, IEEE Standard 830-1998, 1998.
• [11] Miller, Roxanne E. The Quest for Software Requirements: Probing questions to bring nonfunctional requirements into focus. MavenMark Books, LLC, 2009.