What is Requirements Management?

The tasks in requirements management

The tasks in requirements management vary somewhat depending on the perspective. Basically, it is about understanding requirements as a description of a desired functional scope. The goal should be to identify requirements that are correct, complete, unambiguous, consistent, evaluated for importance and/or stability, testable and traceable.

The International Requirements Engineering Board (IREB), for example, lists four central tasks:

• The elicitation of requirements including detailing and refinement.
• The documentation as an adequate description of requirements.
• The examination and coordination of requirements with the aim of ensuring quality.
• The administration – also referred to as requirements management – of requirements.

The IEEE 24765:2017, for example, speaks of

• requirements elicitation,
• requirements analysis,
• requirements specification and
• requirements validation.

Regardless of the subtle differences in the respective perspectives, one point is very important: requirements change. New requirements are added, existing requirements lose their importance. Why? Because stakeholders change their opinions or goals, because new understandings become clearer in the realisation of a product or the implementation of a project, or because there are new laws and standards. It follows that requirements management – and thus the elicitation, analysis, specification and evaluation of requirements – is not a one-time thing at the beginning of a project or a development. On the contrary: it is a continuous task.

Challenges in requirements management

The Standish Group’s CHAOS Report regularly cites unclear requirements as a major factor in failed projects and developments. How do unclear requirements come about? Either they were not formulated clearly, correctly, without contradictions etc. Or there were discrepancies between the wishes of the stakeholders and the implementation of the developers. Or implicit wishes of clients were not explicitly formulated and thus could not be realised by the contractors due to ignorance. Clearly, there are challenges with requirements management. Here are some more examples:

• Requirements management is a complete discipline that requires clear rules and good communication between the parties involved. For example, it is important to clarify who does what when and how, which roles are involved with which responsibilities, rights and duties, which tools are used, how lessons learned from previous projects or good practices from known methods are used.
• Who are the stakeholders, what do they want, which stakeholders are more important than others, how is communication usually done and especially in case of difficulties, etc.? Stakeholder management should provide answers to these questions.¹
• How are requirements prioritised? Is the weighting done, for example, with the MoSCoW Method or with the Kano Model, with absolute values – a requirement with the value 984 is more important than one with the value 983 – or with gradations such as important, very important, incredibly important?
• How can it be ensured that the essential requirements are identified, documented, checked and agreed in good time, so that valid architectural decisions can be made, for example?
• How can the HIPPO effect be avoided, which describes a cognitive bias according to which the opinion of the best-paid person – e.g. in the definition, prioritisation and realisation of requirements – is given more attention?
  There are always users who – intentionally or unintentionally – use a system contrary to its intended purpose. Here, approaches such as misuse cases or chaos engineering can provide useful perspectives.
• How are change requests documented? Who is allowed to make change requests at all and what happens to the costs incurred for the realisation of requirements if these do not end up in the final product due to a change request?
• …

There are many small and large challenges in requirements management. This is another reason why many companies are investing in the training of employees and in personal certificates such as the Certified Professional for Requirements Engineering (CPRE).

Questions in the context of requirements management

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

• What is a good process in requirements management?
• What are the tips for conducting requirements workshops?
• What to do when the amount of requirements gets too big?
• How can requirements be specified within 14 days?
• How does requirements analysis work remotely?
• Does it make sense to manage requirements with MS Excel?
• How can the completeness of specifications be verified?

We are sure you can think of more questions. Feel free to contact us and we will try to answer your questions or publish appropriate articles.

Tools for requirements management

There are various tools in requirements management or requirements engineering. Here is a small list of tools without any claim to completeness or evaluation:

• ReqSuite RM by OSSENO Software
• Polarion Requirements by Siemens
• DOORS Next by IBM
• Helix ALM by Perforce
• Visure Requirements
• TraceCloud
• SpiraTest by Inflecta
• Jira by Atlassian

Of course, 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 can statements be made about deadlines and costs if only some of the requirements are known at the start of the project or development?

Notes:

[1] It is not always easy to make contact with stakeholders or to encourage them to participate actively. Some organisations therefore deliberately choose so-called crowdsourcing as a contextual, punctual, temporary and targeted interaction of a large number of people from outside the company (crowd) to procure knowledge (sourcing).

And here you will find additional information from our Smartpedia section:

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