Continuous change, which, nowadays, is a commonly accepted feature of both business and technical environments, requires continuous change in a business and its supporting systems, including information technology solutions. This, in turn, leads to the need for continuity also in the realm of requirements engineering. It is necessary to be aware whether it is necessary to change the requirements, why and when this should be done; and how to handle the related changes in the environment, business, system, systems development process, and systems maintenance. To find out how to answer at least part of these questions, the FREEDOM framework is established by analyzing different configurations of work systems and also information and knowledge flows in a viable systems model. The paper focuses on propagation and feedback relationships among the requirements engineering function and other constituents of the FREEDOM framework.
1 Introduction
In the situation when the business environment changes very rapidly, new approaches
to systems development are needed. One of the solutions is agility. However, agility
alone can cause chaotic systems growth [
The FREEDOM framework has the following constituents (see Figure 1): F - Future representation, R - Reality representation, E1 - requirements Engineering, E2 fulfillment Engineering, D - Design and implementation, O - Operations, and M Management.
The constituents of the framework should be viewed as functions with changeable granularity, e.g., E2 - fulfillment Engineering can be fully "moved into (inside of)" E1 requirements Engineering, and form function EE - requirements Engineering and fulfillment Engineering; or D - Design and implementation can be fully "moved into" E - fulfillment Engineering and form function ED - fulfillment Engineering, Design and implementation; and so forth.
F - Future representation is the constituent of the framework that is responsible
for representation of the To-Be situation, i.e., the representation of a vision of the
target system in its context. Artifacts that are developed by this function are mainly
different enterprise models [
R - Reality representation is responsible for all artifacts that represent the present (As-Is) situation. The types of these artifacts are similar to those of F, with just the difference that here the information is about the current situation. Like in F, the contents may be developed by R itself or by other constituents of the FREEDOM framework. Information available in databases, warehouses, and other IT systems also may belong to R. The mapping and traceability between F and R is to be established and maintained - this is one of the challenges of contemporary enterprises. E1 - requirements Engineering is the function dedicated to the model and tool based acquisition and management of high quality requirements that can be used by functions on the right from E1. E1 to a large extent can help to meet the challenge mentioned in the previous paragraph. It also can richly contribute to F and R.
E2 - fulfillment Engineering is the function that takes care of handling project
portfolios, that would lead to the fulfillment of stated requirements. It is common to
put the design next to the requirements engineering [
D - Design and implementation is the function that produces the design and handles implementation of the target system. The border between the design and implementation may be more or less strict depending on the fulfillment strategies, methods, chosen lifecycles, and guidelines established in E2.
O - Operations regard the actual operation of the implemented system, including its maintenance.
M - Management refers to all levels of management under which the target system operates. The management can influence both the reality and its representation function R (see brown arrow in Figure 1) and the future vision and its representation function F (see green arrow in Figure 1).
It is assumed that knowledge continuously propagates from E1 towards O in a managed and transparent way. It is also assumed that each function can acquire information from other functions and can provide feedback to other functions. The management function can provide direct requests for actions to all other functions. All functions can have the capability to acquire information from the wider external environment beyond the reach of F and R. In the next section we will look more closely at how E1 deals with information in the case of continuous requirements engineering. From the functional point of view requirements engineering is an information processing function. Therefore, embedment of continuous requirements engineering in the FREEDOM framework will be discussed from the point of view of "information relationships" between requirements Engineering (E1), which in this case is continuous requirements engineering; and other constituents of the framework. The "information relationships" are represented in Figure 3, however, here the information and knowledge flows between F and other elements of the framework, R and other elements of the framework, and some other "information relationships" are not shown for the sake of clarity of representation. These flows are shown in Figure 1 and Figure 2 (Figure 2 represents only flows with respect to F, but the representation of the flows for R is very similar). requirements engineering should be aware of scientific discoveries, new available technologies, competitive solutions, etc.). Requests from management (M), which can directly provide information about necessary deliverables of E1.
The above list of "information relationships" shows the spectrum of information handling variability in continuous requirements engineering. Taking into consideration this spectrum, it is clear, first, that continuous requirements engineering has to deal with complex information handling tasks; second, handling of these tasks requires appropriate IT tool support; and, third, the handling of the information will require manual, semi-automatic, and fully automatic functions.
Another issue to be taken into consideration is the fact that the structure (granularity of constituents - see Section 2) of the FREEDOM framework can change according to particular enterprise and project situations. This may require a different number of constituents with which the "information relationships" are established, but it should not exclude any of the relationships mentioned in the list presented above.
With the purpose to better understand the phenomenon of continuous requirements
engineering, this paper analyzed the continuous requirements engineering function in
the context of the FREEDOM framework, which has emerged from related research
in worksystems based systems engineering and systems viability. The use of the
framework helped to identify main information units to be handled by continuous
requirements engineering. To some extent, it also allows assessment of the
complexity and variability of the tasks of continuous requirements engineering. We
can conclude that, besides the regular "duties" of requirements engineering [
In this position paper only "What?" with respect to continuous requirements engineering was considered. The detailed proposals of how to integrate all issues discussed in this paper in continuous requirements engineering processes is the subject of further research. This work is supported in part by the Latvian National research program SOPHIS under grant agreement Nr.10-4/VPP-4/11.