Timbus - Timeless Business

Blog Post: Requirements and Capabilities

Details

Created on Friday, 15 March 2013 00:00

Last Updated on Tuesday, 21 October 2014 08:32

To address engineering problems, understanding the potential solutions as “a system” has proved to be a relevant concept. In such scenarios, Requirements Engineering (RE) techniques are used to discover the purpose, scope, stakeholders, actors and all the relevant requirements of the system being specified. Those first activities can be classified as the requirements development process, whereas the activities of evolving accepted requirements (e.g. dealing with changes requests, impact analysis, tracing, and status-tracking) can be regarded as the requirements management process.

RE is an established and distinct field of research and practice with more than four decades that evolved from being concerned with software systems to a broader perspective that also covers aspects of systems and organizations. Also, the scope of what is considered a requirement artefact has changed. Initially, RE mainly considered textual requirements written in natural language, whereas now requirements artefacts range from textual requirements to proper formal languages, models, scenarios, and goals. It has been proved that the use of these multiple artefacts offers several advantages to the RE process. Aligned with that, we argue that in some situations the concept of capability can also be useful and necessary, especially when dealing with contexts of some complexity.

Organizations often opt for the acquisition of off-the-shelf systems or components developed to fill generic needs, which then require customization and configuration in order to fulfill their specific needs. Reality can turn out even more complex, involving sometimes the adoption and integration of off-the-shelf solutions into systems-of-systems, or even the reutilization of existing solutions in different settings than those for which they were conceived initially. In these scenarios, the usage of a traditional engineering life cycle might not be the most adequate, since in fact the final product is not being engineered from scratch. In such cases, the original requirements specifications might not be available or accessible. Additionally, reusing off-the-shelf or already available components motivated only by the requirements they are perceived to support, does not consider their full potential.  Such fact alone might result in a dumb down usage of the existing technology, which might work as a blindfold to innovation.

In either case, traditional RE processes might not work as expected. In other words, it becomes important to know what a system is actually able to do and not only what it was purportedly designed for. In those scenarios we believe the concept to support this approach is the concept of capability.

The relationship between capability and requirement has been explored before. The term capability is in fact referred in the definition of requirement provided in ISO/IEC/IEEE 24765 (Systems and Software Engineering – Vocabulary, 2010): “a condition or capability needed by the user to solve a problem or achieve an objective”. These concepts are depicted on Figure 1, and can be described as follows. Usually, the customer expresses his intentions by the means of goals and, in order to achieve his intentions, he has needs which are usually expressed using requirements. In that sense, the relationship existing between requirement and capability could be one of need: capabilities can be designed to satisfy the needs of the customer, which are expressed through requirements. The documented expression of requirements has to satisfy the goals of the customer. Capabilities are thus a means for achieving goals, satisfying one or more requirements posed by the customer.

However there are still several challenges to be solved in order to make possible the usage of the concept of capability in RE. In methodological terms, a new approach is needed for RE which includes the concept of capability. This need arises from the fact that existing systems engineering methods do not take into account the possibility of using systems for new purposes, which might be different from the original ones. Associated with the previous point, there is a need for techniques that support the identification and representation of capabilities, either designed (i.e. intentionally built into the system) or emerging (i.e. potential capabilities that can exist and allow the use of the system from purposes others that the original ones).

The relevance of this approach for digital preservation might not be valuable for newly designed systems, where digital preservation requirements might be properly considered. However, that changes when addressing scenarios with digital preservation requirements where existing business information systems have to be taken in account. The huge universe of actual deployed business information systems that were designed without taking digital preservation requirements into consideration but that have to address them now is a big motivation for this approach. The expected value of such an approach will be the optimization of these systems by taking the best advantage of their capabilities. If such capabilities are properly identified, then the need for new (and expensive) developments in new complementary systems, or in new functionalities that might be already developed in the actual system’s capabilities, might be avoided.

As business information systems are a crucial aspect of the infrastructure supporting the execution of business processes, then their preservation is also one of the crucial aspects when dealing with business process preservation.  As such, this approach is currently being explored in the TIMBUS Project. The aim is to develop an assessment method for determining if the assessed systems possess the capabilities that allow their preservation and redeployment in the future.

Please register in order to comment