Requirements Management. The Foundation of Successful Projects.
What does requirements management mean? How do you carry it out? And how can you proceed in an agile manner?
Requirements describe a desired product. The more precisely requirements are formulated, the better they can be fulfilled. But it is not always possible to concretize all wishes before development. Then one must proceed iteratively-incrementally.
The exchange of information at the interface between stakeholders and developers is the core task of requirements management.
The more precise, unambiguous, complete, understandable and traceable requirements are, the easier it is for development to meet them and deliver the right results.
Requirements management plays a crucial role for projects of all kinds, because requirements define what is to be developed. Management includes the steering, control and administration of requirements throughout their entire life cycle. This also includes risk management, change management, and requirements realization management.
By definition, requirements management is a component of requirements engineering (RE) and business analysis (BA). Requirements definition, requirements analysis, requirements documentation and requirements validation are seen as additional disciplines and not as a component of requirements management.
Because requirements can change quickly and frequently, the particular challenge in requirements management is to establish traceability and collaboration without loss of information.
Definition according to IREB® Glossary
The process of managing existing requirements and requirements related work products, including the storing, changing and tracing of requirements (traceability).
Classical Requirements Management
The classic requirements management process follows a phase or waterfall model:
First, stakeholders and requirements are identified and captured. One or more requirements engineers then analyze, model, structure, and refine all requirements. The results of the requirements analysis are finally documented in the form of requirements specifications (from the client side) and/or functional specifications (from the contractor side). These documents are used for precise specification before the start of development. Only when the requirements are verified, the realization is started. Once development is complete, one or more test stages (validation) follow and, if the requirements are met, accepted. For development maintenance, requirements must continue to be managed securely throughout the development lifecycle.
If changes to requirements are desired, change requests must be submitted. The requirements affected by the changes are then identified and revised, taking into account all dependencies.
Requirements management is required in all phases because its task is to manage work products. Products are both simple requirements and entire specifications. Management includes meaningful attribution, filtering, prioritization and versioning. And above all, ensuring traceability. The work products must be prepared in such a way that everyone who processes, implements and tests them can work together efficiently.
A linear requirements management process is required to ensure quality and to comply with standards, but it is not particularly well suited when requirements are very vague at the outset, when innovation needs to emerge, or when there is a need to respond quickly and directly to stakeholder feedback.
Definition according to BABOK® (Business Analysis Body of Knowledgt) Guide
Planning, executing, monitoring, and controlling any or all of the work associated with requirements elicitation and collaboration, requirements analysis and design, and requirements life cycle management.
Agile Requirements Management
In agile approach, the one big process is broken down into many smaller units (iterations). The cycle length and frequency of the iterations are fixed. The elicitation, analysis, specification and verification of requirements is never complete, but an ongoing activity:
There is a superordinate source of requirements: the Product Backlog. The guiding principle for the requirements in it is the product goal, the objective of the development. A product owner is responsible for ensuring that content, so-called product backlog items, are sorted, clear and coordinated. His/her job is to maintain the Product Backlog so that maximum value can be created. Unlike a specification, the Product Backlog is never complete. Changes can be made at any time, as long as they add value.
For realization within an iteration (a sprint with a duration of 2 – 4 weeks), items from the Product Backlog are transferred to a Sprint Backlog at the Sprint Planning Meeting. In addition, a Sprint Goal is defined for the iteration. Even during the Sprint, the developers can change the Sprint Backlog to achieve the Sprint Goal. Finally, the development team manages itself and is responsible for results.
To ensure that development results are always reviewed in between, there is a Sprint Review at the end of each Sprint, where feedback can be obtained from stakeholders. The results of this control meeting immediately flow back into the backlog.
To further improve the work process, a retrospective also takes place within the Scrum team. Due to the significantly shorter feedback loop, undesirable developments can be identified earlier and changes can be reacted to much faster. But this also ensures dynamics within the product backlog, which is why it must be continuously updated, maintained, prioritized and refined.
Nevertheless, the product owner is not solely responsible for the requirements, but all participants are responsible for creating value through the realization of the requirements. In order to standardize work products (e.g. user stories), sentence templates, quality characteristics (such as SMART, INVEST) and acceptance criteria are often defined, the application of which is binding for everyone in the team. However, maintaining the product backlog, the central repository of all requirements, is a task of great responsibility. Agile methods specify that the business value must be questioned for all entries in the product backlog. As a result, the product owner is even involved in strategic management. One could therefore say that product ownership means even more responsibility than classic requirements management.
Definition of requirements management according to Glossary of ISO/IEC/IEEE 24765:2017 Systems and Software Engineering
Activities that ensure requirements are identified, documented, maintained, communicated and traced throughout the life cycle of a system, product, or service.
Tools for Requirements Management
In many companies, requirements are still managed in Excel lists. However, if many employees work with and on these lists in a division of labor, clear version management already becomes a problem. Good requirements management requires versioning, configuration management, baselining and a single point of information. Wikis can help to build a common glossary and thus define terms unambiguously for all participants. Dependencies, processes or refinements can be visualized with mind maps, but often not versioned. Groupware or separate project management software is used for collaboration. Validation is managed in special test management tools. This patchwork of different tools can be found in many places, but special requirements engineering tools offer clear advantages, such as:
Management of work products with attributes (incl. filters and queries)
Organization of work products (with hierarchical structures)
Configuration and version management at work product level
Definition of requirements baselines (baselining)
Multi-user access and management (roles and rights concepts)
Ensuring traceability (traceability management)
Review management of the work products
Change management (workflows for state transitions)
Professional Requirements Engineering in Practice
Learn more about requirements engineering with objectiF RPM or objectiF RM »
