The standard also contains additional suggestions on how the requirements could be further refined in order to achieve a specification that is as complete as possible. A specification can only be considered complete if all types of requirements are defined. This is an essential basis for the success of a development project and the resulting product. However, the question arises as to how we arrive at the requirements.

Elicitation

There are various sources for requirements. These include:

• Stakeholders: these are internal and external persons or institutions that make direct or indirect demands on the system.
• Documents: laws, standards, manuals or other documentation can be used to determine requirements.
• Systems: it is often helpful to look at a predecessor system or a competitor product. The peripheral systems that place requirements on the system to be developed must also be taken into account.

The relevant information is obtained through the use of elicitation techniques. These include creativity, observation, questioning and artefact-based techniques. The elicitation techniques are selected depending on the requirement category. CSA often organises a systems engineering workshop at the start of a project where the main functions of the system, the peripheral systems and the system boundaries are defined.

Documentation

The successful use of elicitation techniques results in a wide range of information being gathered. The documentation of this information not only serves to make this knowledge available to all project participants, but also to structure the knowledge collected. The form of documentation can be chosen between natural language and requirements models or a mixture of both.

There is a whole range of tools available to support the requirements lifecycle. For efficient and successful RE, there are also many requirements that apply to these tools, which will be explained in a future blog post.
Verification and validation

Once the requirements have been documented, they should be verified and validated against the other requirements. This can be done, for example, in parallel with the documentation process by asking the stakeholders concerned or by means of an informal review. Once the requirements have reached a certain level of maturity, it is advisable to subject them to a review. This ensures that they meet the specified quality criteria. Incorrect requirements can influence development activities. The later an error is recognised, the more changes have to be corrected, which in turn costs time and money. Requirements may also contradict each other; these conflicts must be resolved.

Management

Once the requirements have been recorded, documented and checked, the next step is to manage them. Requirements management comprises the processes that support the requirements analysis and the further use of the requirements. It comes into play, for example, when requirements change. For this reason, using attributes for requirements is recommended. Filters provide a better overview of the requirements specification, improving traceability. This in turn is a great help during impact analysis.

Summary

Requirements engineering is a demanding field featuring a wide range of activities. The application of professional requirements engineering increases the chances of a project’s success, because a well-founded analysis ensures that

• the product to be developed meets the needs of the stakeholders,
• all key aspects are taken into account,
• only what is necessary is developed.

The initial outlay may seem high, but it is worth it. You can save a lot of money and time in the future if you establish the right direction for a project’s development from the outset.

We have in-depth knowledge of requirements engineering, which enables us to select and apply the appropriate methods for each project. By optimising the project, a solid basis can be created right from the start.

We would be happy to help you with your project. Please do not hesitate to contact us.