What is Requirements Engineering?

The activities of Requirements Engineering

Many definitions of requirements engineering vary in detail. The International Requirements Engineering Board (IREB), which tries to professionalise both RE and business analysis (BA), names four central activities:

• The elicitation / determination of requirements including detailing and refinement
• The documentation as an adequate description of requirements
• The validation – examination and coordination – of requirements with the aim of ensuring quality
• The management of requirements

The International Institute of Business Analysis (IIBA) addresses, for example, the requirements elicitation of stakeholders, requirements management including communication, and requirements analysis. And IEEE 24765:2017 speaks of requirements elicitation, requirements analysis, requirements specification and requirements validation.

Because of these different definitions and interpretations, many terms are also used synonymously with requirements engineering. Especially requirements management and requirements analysis are often mentioned. However, these terms can also be subsumed under RE. It is important here that there is clarity between the communication partners so that no misunderstandings arise.

Reasons for Requirements Engineering

There are a number of good reasons for performing requirements engineering:

• What do the stakeholders expect? Only those who know what stakeholders expect will be able to develop a product that meets their expectations. For this reason, stakeholder management, consisting of identification, analysis and communication, is a central component of RE.
• Technical systems and software can only be successfully implemented if there is a complete, clear and consistent specification of all requirements – for example in the form of a SRS. The creation of such a specification is the task of RE.
• nly those who know at least a substantial part of the requirements can begin to make forecasts of dates and costs, design plans and communicate them. RE is therefore a central component not only in product development, but in the entire company.
• Requirements engineering helps to reduce development costs, because ideally, undesirable developments can be avoided or at least identified early on. For example, correcting a misunderstood requirement in an early phase of development is much cheaper than correcting the implemented feature in an application or system during operation. Consequently, lower support costs also apply.
• Boundary conditions, functional requirements, enthusiasm characteristics, goals, but also standards and laws etc. often change already during the development phase, but certainly during the operation of a solution. RE creates the basis for the further development of products, systems or software. And this is also the reason why publications aimed at declaring requirements engineering as a phase activity at the beginning of a development overlook an important point: RE is a continuous task.
• Last but not least, the Standish Group’s CHAOS Report regularly cites unclear requirements as a major factor in failed projects and developments.

For all the reasons that speak in favor of requirements engineering, there is one aspect that should still be considered: From an economic point of view, RE only has an indirect effect, for example by reducing costs or increasing customer satisfaction. However, RE as an activity always causes costs. So here it is important for organisations to find a “reasonable balance”.

Questions in the context of Requirements Engineering

There is a long list of questions in the context of RE. You can find answers to some of the questions in our blog:

• What is a good process in requirements management?
• How important is the “why” in requirements management?
• What tips are there for conducting requirements workshops?
• What to do if the mountain of requirements becomes too large?
• How can requirements be specified within 14 days?
• What are the biggest obstacles in requirements engineering?
• What are typical misunderstandings in requirements engineering?
• What prevents creativity in requirements engineering?
• How can requirements be raised destructively?
• How does requirements analysis work remotely?
• What actually is agile requirements engineering?

Surely you can think of further questions. Feel free to contact us, we will try to answer the questions or publish corresponding articles.

Tools for Requirements Engineering

There are many tools in requirements engineering. Here you will find a small list of tools without claim to completeness and without evaluation:

• YAKINDU by Itemis
• Polarion Requirements by Siemens
• DOORS Next by IBM
• Enterprise Architekt by Sparx Systems
• Reqtify by Dassault Systems
• Reqchecker by Khilogic
• Helix ALM by Perforce
• Visure Requirements
• TraceCloud
• Cradle by 3SL
• SpiraTest by Inflecta

Certainly, the list can easily be extended, especially since there are numerous products that are used in organisations for working with requirements (e.g. MS Excel or MS Word), but originally have a different marketing focus. 

How important is continuous requirements engineering for the success of your product development?

Notes:

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

Here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.