In the last years, computer systems have become more and more important for everyday life. They control an increasing number of everyday systems such as e-business systems, but also critical systems, e.g. medical systems, or nuclear reactors. This also means that the software controlling these systems has become bigger and increasingly complex. Good - complete, and well-understood - requirements are a prerequisite for successful projects, even more so for complex ones. Without understanding / determining what the customer (really) wants and needs, and writing this down in a concise, understandable and testable manner, projects not only won't lead to what the customer wanted, but they probably won't work correctly or even not at all.

This is well-known: all established software development processes encompass workflows for determining, analysing and maintaining requirements, and standards such as ISO 9000 ensure that these workflows are used in a correct way. One problem with large software development projects however is that the thorough elicitation of requirements often leads to long and all-containing documents with hundreds of pages that are written from scratch. The problems stemming from this can easily be seen:

• Even though it is rare the domain and project content is completely new to the company, past experiences and results are neglected. So, the same mistakes as in earlier projects are probably made again: requirements that earlier have only been found during the project are not considered (e.g. technical requirements, change requests), and benefits/lessons learned in successful earlier projects are ignored.


• It is not unusual that the produced requirement documents are incomplete and inconsistent. It is impossible to determine all requirements upfront. Rather, the completeness comes during the course of the project as questions arise and details need to be refined. Missing requirements that are not detected until the implementing phase however can result in major architectural changes and thus induce highly increased total project costs.


• A completely new project does not take into account existing programs and software components if they are not explicitly searched for. This is especially true for software developed in the same company, e.g. from earlier projects. The main reason is that most of the time nobody knows that such components exist.

Obviously it would be better to reuse from other (older) projects, and from other information sources. Reusing here is more than using the layout and structure of documents though. It is leveraging past facts and experiences and learn from errors made in these projects, so as not to make them again. As a result the requirements are more complete even initially, contain fewer errors, and they are determined faster.

All these problems are neither new nor specific to requirements engineering. They are relevant to all businesses, especially those that undertake projects with customers. The question was: How can be determined what is already known, and how can this knowledge be preserved and made available for usage.

The solution to this question led to the discipline of Knowledge Management. This discipline deals with the identification, management, and preservation of knowledge by offering processes, mechanisms, guidelines and tools for working with the knowledge.

The approach of the KOGITO research project is to integrate knowledge management with requirements engineering to leverage the benefits of knowledge management in order to create a better requirements engineering experience. The basic idea is that requirements and related artefacts are also knowledge, so why not using knowledge management instruments with them.

KOGITO also exploits one important aspect of requirements engineering: It can benefit much from tools. Beginning with the identification of requirements (leading to the generation of documents) to the actual implementation and its testing (working in integrated development environments), in software development tools are usually used to work with the requirements and related artefacts. So an approach for integrating knowledge management with requirements engineering should not only provide workflows and guidelines but in-depth tool support.

This also provides for the necessarily tight control regime during projects as the correct handling of requirements is of utmost importance to the success of the project:

• Wrongly reusing requirements can lead to disaster. One famous example of this is the Ariane 5 disaster where the wrong reuse of the requirements and software of the Ariane 4 lead to the total destruction of the new Ariane 5 rocket.


• Requirements do change. The development of software is based on assumptions made in the requirements. Changing the requirements due to emergence of inconsistencies between the documented and the actual requirements leads to a change of assumptions. The goal is that requirements documents stay alive during the project - they must not be paper on the shelf, but have to reflect the actual knowledge about what the customer wants and needs and thus gets.


• Requirements need to be used by all relevant parties, not only the customer and the requirement engineers. If for instance the developers do not see the requirements, they probably won't implement them rather but their own perceptions.


• Requirements and related material need to be maintained (stored and managed) during and after the project in a consistent manner, and be made accessible to everybody that should have to access to it. Only then they are available for later reuse.

The KOGITO project affiliates widely accepted and proved techniques of requirements management with new and innovative methods of knowledge management in order to create a prototype for an integrated requirements engineering environment. This environment helps to

• consistently and thoroughly elicit the customer needs,


• save time and cost by re-using requirements, experiences and technical solutions from past project and other knowledge sources, and


• trace the requirements through the entire development.

Thereby, a company using the KOGITO environment will be able to estimate the progress and secure the realization of all customers need, and in result achieve a better quality and customer satisfaction.

The six core principles of KOGITO

1. Not another tool

The plethora of tools used in software development makes it difficult to provide consistent access to knowledge. This problem can be handled in two ways: create one tool that does everything, or enhance the existing tools.

In KOGITO, we think that the latter way is the better way as it avoids major changes to the working environments of people - they can use their same tools, the only visible change being that these tools now can do more than before, and so don't have to learn new tools.

The KOGITO environment reflects this approach: It integrates with existing and widely-used tools used in software development such as the word processor Microsoft Word or the development environment Eclipse.

It also provides an always accessible web interface that is not bound to a particular tool but can be used in any working environment.

Using KOGITO, there is no need to learn new tools, just use the extended abilities provided by the KOGITO add-ons to tools already in use, for managing and working with the requirements.

2. Everybody speaks the same language

One major problem in requirements engineering is that different persons use different terms and also understand them differently. Customers use the terms of their domains (e.g. banking, flight engineering etc.) whereas software developers have terms of their own. As the result, a developer might not understand what the customer says and vice versa.

A comprehensive glossary helps solving this problem. It defines a common terminology for analysts, developers and stakeholders by containing definitions of all relevant terms as well as their known (domain specific) synonyms and homonyms.

In KOGITO, the glossary functionality is available throughout the system (in all tools and in the web front-end), so it is everywhere where it might be needed. This makes it easy to use the correct terms, and thereby to understand what the requirements mean.

3. (Re)Use everywhere

Using and reusing knowledge requires two things: It must be known that there is knowledge, and the knowledge must be easily accessible and usable.

KOGITO makes other projects (older ones and current) and knowledge bases (e.g. for domain knowledge, software engineering knowledge), readily available to the project. Also, the project's glossary integrates with glossaries from these other knowledge sources.

This makes it easy to use the knowledge contained therein providing for reusing what is needed when it is needed.

4. History in the making

Requirements change, so artefacts and other information will change, as well. It is important that everybody has access to the current versions. On the other hand, it is sometimes necessary to access older versions for instance to see how and why something changed.

KOGITO provides a central repository for all requirements, related documents and development artefacts. The repository stores all versions so you can always see the way a document has evolved.

The direct support of the change request mechanisms of modern software development processes automatically leads to the recording of the relevant information (who, when, what, …) of change.

5. Documents made easy

With KOGITO documents are generated when they are needed from the knowledge (requirements, artefacts etc.) contained in the system. This ends the problem of the multitude of documents, or their opposite, the long, all-embracing specification document, that have to be maintained. In the KOGITO environment, a specification document always contains the current requirements, it is never out of date.

Pre-defined or user-supplied templates are used to define structure and layout of the documents, for instance for specification documents or feature lists.

With the versioning support in KOGITO, documents can be generated as a "snapshot" view of the requirements, e.g. based on a specific date or of a specific baseline for an older version.

6. It fits right in

KOGITO does not define a new software development process. Rather, it defines workflows, guidelines, and provides templates and tools that are easily integrated into existing modern software development processes such as the Rational Unified Process.