Requirements Management: A Complete Guide to Requirements, Traceability and Better Development Projects

What is requirements management?

Requirements management is the work of ensuring that requirements are identified, understood, documented, communicated, analyzed, prioritized, traced and kept up to date throughout the entire development process. It is not just about writing a requirements specification at the beginning of a project. It is about creating a living structure where needs, decisions, dependencies, changes and verification are connected.

A simple definition is that requirements management answers four fundamental questions:

• What should the solution be able to do?
• Why is this needed?
• Who is affected by the requirement?
• How do we know that the requirement has been fulfilled?

In smaller projects, requirements management can sometimes be perceived as something administrative. In larger organizations, regulated industries and complex systems development, it is often the opposite: one of the most important prerequisites for success. When many teams, roles, suppliers, systems and regulations need to work together, everyone must be able to trust that the requirements are clear, current and traceable.

Requirements management is used in many areas: systems development, software development, product development, medical technology, defense, finance, energy, manufacturing, the public sector and other environments where it is important to develop the right solution in a controlled way.

Requirements management compared to requirements analysis

The terms requirements management and requirements analysis are sometimes used as if they mean the same thing, but they have different areas of emphasis.

• Requirements analysis is primarily about understanding needs, analyzing problems, formulating requirements and ensuring that the requirements are reasonable, clear and feasible.
• Requirements management is broader and also includes structure, versions, traceability, status, prioritization, change management, review, approval and follow-up over time.

You could say that requirements analysis helps the organization formulate the right requirements, while requirements management helps the organization control and maintain the requirements throughout the entire lifecycle.

Why is requirements management important?

Many projects do not fail because the team lacks competence, but because there is uncertainty about what should actually be delivered. Unclear requirements lead to different interpretations, late changes, incorrect priorities, costly rework and solutions that do not meet real needs.

Effective requirements management enables the organization to work in a more controlled way, even when the project is complex and conditions change. It helps the team make better decisions, identify risks earlier and demonstrate that the solution meets requirements from customers, users, the business and regulations.

The most important benefits of requirements management

• Clearer goals: The team gets a shared understanding of what should be achieved and why.
• Less rework: Incorrect assumptions and misunderstandings are discovered earlier.
• Better prioritization: Requirements can be evaluated based on value, risk, cost and feasibility.
• Increased traceability: It becomes possible to follow a need from origin to design, implementation, test and delivery.
• Controlled changes: New requirements and change requests can be assessed before they affect schedule, budget and architecture.
• Better compliance: The organization can show how regulatory requirements, standards and internal policies have been handled.
• Stronger collaboration: Business, technology, test, management and external stakeholders work from the same decision basis.

For organizations developing safety-critical, regulated or technically advanced systems, requirements management is not just a project method. It is part of quality assurance. Without clear requirements, it becomes difficult to prove that the right thing has been built, that it works and that it meets the applicable requirements.

What is a requirement?

A requirement describes a need, characteristic, function, constraint or condition that a solution must fulfill. The requirement may come from a customer, a user, an authority, a standard, a business strategy, a technical dependency or an internal process.

A requirement can be simple, such as a user being able to log in with BankID. It can also be very complex, such as a system having to meet specific security, performance and traceability requirements in a regulated environment.

The important thing is that the requirement is clear enough to be understood, implemented, reviewed and verified.

Example of an unclear requirement

The system should be fast and user-friendly.

It sounds reasonable, but it is difficult to test. What does fast mean? For whom? In what situation? What does user-friendly mean?

Example of a clearer requirement

A registered user shall be able to open their overview page within two seconds under normal load, measured from the moment the user clicks the menu option until the page is fully loaded.

This requirement is more useful because it describes the user, the situation, the expected behavior and a measurable criterion.

What characterizes a good requirement?

A good requirement is not necessarily long or technically advanced. The most important thing is that the requirement is understandable, relevant and possible to follow up. In practice, a requirement should be readable by several roles without them making completely different interpretations.

Good requirements are often:

• Clear: They can be understood without unnecessary interpretation.
• Unambiguous: They cannot reasonably mean several different things.
• Necessary: They contribute to a real need, goal or regulation.
• Feasible: They can be realized within reasonable technical, financial and time-related constraints.
• Testable: It is possible to determine whether the requirement has been fulfilled or not.
• Traceable: It is possible to see where the requirement comes from and what it affects.
• Prioritized: It is clear how important the requirement is in relation to other requirements.
• Consistent: They do not contradict other requirements.
• Current: They are updated when decisions, conditions or needs change.

Practical checklist for requirement quality

Use the following questions when reviewing requirements:

• Can the requirement be understood without a verbal explanation?
• Is it clear who or what the requirement applies to?
• Does the requirement describe a need or a solution detail that has actually been decided?
• Is there a clear acceptance criterion?
• Can the requirement be verified through testing, review, analysis or demonstration?
• Are priority, status, owner and source documented?
• Are there dependencies to other requirements, risks, test cases or design decisions?
• Is the requirement formulated in a way that can be maintained over time?

Requirements are often improved step by step. First, the need is captured. It is then analyzed, broken down, clarified, prioritized, reviewed and linked to verification. Good requirements management makes this development controlled.

Different types of requirements

Not all requirements are of the same type. By distinguishing between different requirement types, it becomes easier to structure the work, involve the right people and choose the right method for verification.

Functional and non-functional requirements

One of the most common distinctions is between functional requirements and non-functional requirements.

Functional requirements describe what the solution should do. This may involve functions, flows, rules, calculations, integrations or automations. Non-functional requirements describe qualities and constraints, such as performance, security, usability, availability, scalability, reliability and maintainability.

Both types are important. A solution may have the right functionality but still fail if it is too slow, too difficult to use or does not meet the security requirements.

The requirements management process step by step

There is no single requirements process that fits every organization. A small product team, a government agency, a medical technology company and a global industrial company all have different needs. However, there are a number of activities that appear in almost all professional requirements management.

1. Define goals, scope and ways of working

Start by clarifying why the initiative exists. What problem should be solved? What goals should be achieved? What is included and what is outside the scope? Which roles should make decisions about requirements, prioritization and changes?

This is also where you should decide how requirements should be documented, which attributes should be used, how reviews should be performed and which tool should serve as the common source of requirements information.

2. Identify stakeholders

Requirements are rarely better than the understanding of the stakeholders. Therefore, identify who is affected by the solution and who can influence the requirements. This may include end users, customers, product owners, system architects, testers, operations teams, security officers, legal experts, suppliers, authorities or management.

A stakeholder map helps the team see who needs to provide information, who should review and who should approve.

3. Collect needs and requirements

Requirements elicitation is about capturing needs, problems, goals, constraints and ideas. This can be done through interviews, workshops, observations, surveys, user data, support cases, regulatory analysis, prototypes or review of existing documentation.

In this step, it is important not only to ask what someone wants, but also why. Behind a request there is often a need that can be solved in several different ways.

4. Analyze and formulate requirements

Once the material has been collected, it needs to be analyzed. Duplicates should be removed, conflicting requirements should be handled, unclear needs should be clarified and requirements should be broken down to a level where they can be understood and verified.

Here, requirements are formulated in a way that makes them usable in development, testing, procurement or maintenance. It may also be relevant to create models, process flows, concept models, use cases or user stories to clarify the context.

5. Prioritize and make decisions

All requirements can rarely be realized at the same time. Requirements therefore need to be prioritized. Prioritization should not only be about who shouts the loudest. It should be based on business value, user value, risk, cost, technical feasibility, regulatory requirements and dependencies.

This is often where requirements management becomes a management issue. By creating transparency around priorities, the organization can make better decisions about time, budget, scope and delivery plans.

6. Document and structure

Requirements need to exist in a place where the right people can find, understand and update them. In professional environments, individual documents in folders are rarely enough. Requirements need to have status, owner, version, priority, source, relationships, comments and history.

A good structure makes it possible to filter requirements, create views for different roles, export specifications, create reports and see which requirements are approved, changed or under review.

7. Review and validate

Requirements should be reviewed before they become governing. The purpose is to ensure that they are clear, necessary, feasible and aligned with the goals. Review can be done in workshop form, as a formal review or directly in a requirements management tool.

Validation means checking that the requirements describe the right needs. Verification means later checking that the solution fulfills the requirements. Both are needed.

8. Create traceability

Traceability means that requirements are linked to other relevant objects, such as higher-level goals, design decisions, test cases, risks, defects, code changes or regulatory sources. This allows you to understand the consequences of changes and prove that requirements have been handled all the way through to verification.

9. Manage changes

Requirements change. New needs arise, technology choices change, the market moves, regulations are updated and stakeholders learn more during the course of the project. A clear process for change management is therefore needed.

A change should be assessed based on value, risk, impact, cost and dependencies before it is approved. Without change control, the project risks losing control of its scope.

10. Verify, validate and follow up

Finally, the requirements must be followed up. Have they been implemented? Are the test cases approved? Are there open deviations? Have the stakeholders accepted the solution? Is it possible to show which requirements were included in the delivery?

This is where traceability shows its value. If requirements, tests and results are connected, the organization can make decisions based on facts rather than gut feeling.

Requirements elicitation: methods and techniques

Requirements elicitation is more than asking stakeholders what they want. Users and buyers often know a lot about their problems, but less about how those needs should be formulated as requirements. A good requirements lead or requirements analyst therefore helps the group move from wishes to clear, testable and prioritized requirements.

Common methods for requirements elicitation

• Interviews: Useful for understanding goals, problems and needs for individual roles.
• Workshops: Effective when several perspectives need to meet and conflicts need to be resolved.
• Observations: Provide insight into how the work is actually done, not only how the process is described.
• Prototypes: Help users react to something concrete and discover missing requirements.
• Process mapping: Shows flows, decision points, dependencies and exceptions.
• Document analysis: Used to identify requirements in contracts, regulations, standards, previous specifications and system documentation.
• Data analysis: Logs, support cases and usage statistics can show recurring problems and needs.
• Risk analysis: Helps the team identify requirements needed to manage safety, quality and compliance.

Questions that help produce better requirements

• What problem are we trying to solve?
• Who is affected by the problem?
• What happens if the need is not met?
• How do users work today?
• What exceptions and special cases exist?
• Which rules, standards or agreements govern the solution?
• How will we measure that the solution works?
• Which other systems, teams or processes are affected?

The more complex the environment, the more important it becomes to combine several methods. Interviews provide depth, workshops create alignment, document analysis secures formal requirements and prototypes reveal details that are otherwise often missed.

Prioritizing requirements

Prioritization is about choosing what should be done first, what can wait and what should not be done at all. It is one of the most valuable activities in requirements management because it connects requirements to business value, risk and feasibility.

Without prioritization, the requirements list easily becomes a wish list. With prioritization, it becomes a decision basis.

Common prioritization models

• MoSCoW: Divides requirements into Must have, Should have, Could have and Won't have.
• Business value versus effort: Compares value with cost and complexity.
• Risk-based prioritization: Prioritizes requirements that reduce major technical, regulatory or business risk.
• Weighted scoring: Requirements are assessed based on several criteria, such as value, cost, risk and time criticality.
• Mandatory before optional: Regulatory and contractual requirements are handled separately because they cannot always be deprioritized.

Prioritization needs to be visible

It is not enough that someone “knows” what is important. Priority should be documented and visible in the requirements tool. This allows developers, testers, architects, product owners and management to understand why some requirements receive more attention than others.

Prioritization should also be reviewed when conditions change. A requirement that was less important at the beginning may become critical after a regulatory change, a customer decision or a technical discovery.

Traceability and requirements traceability matrix

Traceability is a central part of requirements management. It means that you can follow a requirement from its origin to the objects affected by the requirement and onward to verification. Traceability provides control over relationships and makes it possible to answer questions that can otherwise be difficult:

• Which customer need is behind this requirement?
• Which design decisions are based on the requirement?
• Which test cases verify the requirement?
• Which requirements are affected if we change this function?
• Which requirements lack test coverage?
• Which regulatory requirements are included in this version?

What is a requirements traceability matrix?

A requirements traceability matrix, often called an RTM, is a structure that shows the connection between requirements and other objects. This may be requirements to test cases, requirements to design, requirements to risks or requirements to regulatory sources.

In simple projects, a traceability matrix can exist in a spreadsheet. In larger or more regulated environments, it is much better to manage traceability in a requirements management tool, because the relationships can then be updated, filtered, reported and reviewed in a controlled way.

Example of a traceability chain

1. Business goal: Reduce the handling time for customer cases.
2. User requirement: The case handler shall be able to see the case status and history on the same page.
3. System requirement: The system shall retrieve status data from the case management system via API.
4. Design object: Integration with the case management system’s status endpoint.
5. Test case: Verify that the correct status is displayed for open, paused and closed cases.
6. Test result: Approved in version 1.2.

When the chain is documented, it is possible to see both why the requirement exists and how it has been fulfilled.

Change management and baselines

Requirements almost always change. The question is not whether changes will come, but how they are handled. An organization with weak change management risks scope creep, where the scope grows without adjustments to time, budget or risk.

A good change process makes it possible to receive new ideas and needs without losing control.

What a change process can look like

1. Proposal: A stakeholder submits a new requirement or a change.
2. Clarification: The need, background and desired effect are documented.
3. Impact analysis: The team analyzes the impact on other requirements, design, test, schedule, cost, risk and compliance.
4. Decision: The change is approved, rejected or postponed.
5. Update: Requirements, relationships, test cases and documentation are updated.
6. Communication: Affected roles are informed about the decision.

What is a baseline?

A baseline is a frozen version of the set of requirements at a specific point in time. It is used as a reference for decisions, deliveries, reviews and changes. Baselines are particularly important when many teams work in parallel, when versions and variants need to be managed or when the organization must be able to show what applied at a certain point in time.

With baselines, it becomes easier to see what has changed, why the change was made and which version forms the basis for development or testing.

Agile requirements management

Agile development does not mean that requirements management disappears. It means that requirements are handled iteratively and often closer to the development team. In agile ways of working, requirements can be expressed as epics, features, user stories, acceptance criteria and backlog items. But structure, traceability and quality are still needed.

The difference between traditional and agile requirements management

In more traditional projects, the aim is often to define a large number of requirements early. In agile environments, it is accepted that all details are not known from the start. Requirements develop step by step through dialogue, prioritization, feedback and deliveries.

However, this does not mean that everything should be loosely formulated. Agile requirements also need to be clear enough to be developed, tested and accepted.

Important principles for agile requirements management

• Have a clear product vision: The team needs to understand the direction even if details change.
• Prioritize continuously: The backlog should reflect current value, risk and learning.
• Write good acceptance criteria: They are crucial for the team to know when a story is done.
• Maintain traceability where it is needed: Especially for regulated requirements, safety requirements and integrations.
• Review often: Early feedback reduces the risk of misinterpretation.
• Connect requirements to tests: Automated and manual tests should reflect requirements and acceptance criteria.

Agile requirements management works best when the organization combines flexibility with discipline. The team should be able to change direction when new knowledge emerges, but not lose control over decisions, dependencies and quality.

Requirements management tools

It is possible to start requirements management in documents and spreadsheets, but it quickly becomes difficult when the requirements become numerous, change often or need to be linked to tests, design, risks and versions. That is when a requirements management tool is needed.

A modern requirements management tool helps the organization gather requirements information in one place, create structure, manage versions, connect relationships, create views, carry out reviews and track status.

Features to look for in a requirements management tool

• Central requirements database: A common source for requirements, relationships and status.
• Attributes and metadata: For example priority, owner, status, source, version and risk level.
• Traceability: Ability to link requirements to other requirements, test cases, risks, design and changes.
• Version management: Support for history, baselines, comparisons and change analysis.
• Review and approval: Functions for review, comments and decision flows.
• Reporting: Dashboards, status reports, traceability reports and export options.
• Integrations: Connections to test tools, development tools, issue management and reporting tools.
• Permissions and governance: The right people should be able to see, change, review and approve the right information.
• Scalability: The tool should work even as the number of requirements, teams and product variants grows.

When are documents and Excel no longer enough?

Documents and spreadsheets can work in an early phase, but they have clear limitations. They make it difficult to maintain history, manage parallel versions, create reliable traceability, review changes and ensure that everyone is working with current information.

If the organization needs to be able to answer questions such as “which requirements lack tests?”, “what is affected by this change?” or “which requirements version formed the basis for the delivery?”, it is often time to move to a more specialized requirements management tool.

IBM DOORS Next and IBM Engineering Lifecycle Management

IBM DOORS Next is an established requirements management tool for organizations that need to work in a structured way with requirements in complex systems and software development. It is part of IBM Engineering Lifecycle Management, often abbreviated IBM ELM, where requirements management can be connected with test management, workflows, reporting and other parts of the development lifecycle.

For organizations with large sets of requirements, many stakeholders, regulated processes or a need for traceability, a tool such as IBM DOORS Next can provide better control than standalone documents and manual lists.

Examples of what IBM DOORS Next can support

• Create and structure requirements in modules and hierarchies.
• Manage requirements with attributes, views, filters and status.
• Link requirements to other requirements, test cases, design objects and work items.
• Carry out requirements reviews and collect comments.
• Work with baselines, versions, configurations and variants.
• Create reports and dashboards for follow-up.
• Support traceability from need to verification.

Celeris and requirements management in IBM environments

Celeris works with processes, tools, training and specialist support within requirements management and IBM ELM. This may involve implementing or improving IBM DOORS Next, creating ways of working for traceability, training users, supporting administrators, developing custom widgets or helping organizations get more value from their existing requirements management environment.

For companies already using IBM ELM, the next step is often not simply to “use the tool more”, but to create a way of working where the tool supports the organization’s processes. This means clear requirement types, well-designed attributes, good views, effective review flows, traceability to testing and reporting that actually helps projects and management make decisions.

The right configuration, the right training and the right support can make a major difference. Requirements management is just as much about method and behavior as it is about technology.

Common mistakes in requirements management

Requirements management rarely fails because of one single thing. More often, many small weaknesses together create uncertainty. Here are some common pitfalls.

1. Requirements are written as solutions too early

Stakeholders often formulate wishes as finished solutions. Sometimes that is right, but often the team first needs to understand the need behind the request. Otherwise, there is a risk of building the wrong solution to a real problem.

2. Requirements lack acceptance criteria

If it is not possible to determine when a requirement has been fulfilled, it becomes difficult to test and accept the delivery. Every important requirement should have some form of verification criterion.

3. Requirements are documented but not maintained

A requirements specification that is not updated quickly loses value. Requirements management needs to be an ongoing process, not a one-time activity.

4. Traceability is created too late

If traceability is added at the end of the project, it often becomes expensive, incomplete and uncertain. Traceability should be built into the way of working from the beginning.

5. All requirements are treated as equally important

When everything is top priority, nothing is top priority. The organization needs clear criteria for what is critical, important, desirable or out of scope.

6. The tool is introduced without a process

A requirements management tool does not solve unclear ways of working by itself. The tool needs to support a defined process with clear roles, concepts and decision points.

7. Too few roles are involved

If requirements are only formulated by one group, important perspectives are often missed. Business, technology, test, security, operations and users may all need to contribute.

8. Changes are handled informally

Small changes can have major consequences. Changes should therefore be documented, analyzed and decided in a way that is visible to those affected.

How to get started with better requirements management

Getting started with better requirements management does not have to be complicated. The important thing is to create a practical structure that can be used in real projects.

Practical starting plan

1. Analyze the current situation: How are requirements written, stored, reviewed and changed today?
2. Identify the biggest problems: Are the issues unclear requirements, weak traceability, late changes, poor test coverage or lack of overview?
3. Define common concepts: Define what you mean by need, requirement, user requirement, system requirement, risk, test case and baseline.
4. Create a simple requirements model: Decide on requirement types, attributes, statuses and relationships.
5. Introduce review routines: Requirements should be reviewed before they become governing.
6. Start with traceability where the value is greatest: For example between regulatory requirements, system requirements and test cases.
7. Choose or improve tool support: Make sure the tool supports the process, not the other way around.
8. Train users and administrators: A good tool only has an effect when people use it in the right way.
9. Follow up and improve: Measure, for example, requirement quality, change volume, test coverage and the number of unclear requirements.

When should you get help?

It may be wise to bring in external expertise when the organization is introducing a new requirements management tool, migrating from old solutions, creating traceability in a regulated environment, improving IBM DOORS Next, training many users or defining a requirements process that needs to work across several projects and departments.

External support can also be valuable when the organization is stuck in old document-based ways of working and needs to move toward more structured, traceable and data-driven requirements management.

Frequently asked questions about requirements management

What does requirements management mean?

Requirements management means working in a structured way to identify, document, analyze, prioritize, communicate, trace and change requirements throughout the entire lifecycle of a system, product or service.

What is kravhantering in English?

The Swedish term kravhantering is usually translated as requirements management. In some contexts, the term requirements leadership or requirements governance may also be used, especially when emphasizing control, responsibility and process.

What is the difference between requirements management and requirements elicitation?

Requirements elicitation is one activity where needs and requirements are captured from stakeholders, documents, regulations and other sources. Requirements management covers the entire lifecycle: analysis, documentation, prioritization, traceability, changes, review and follow-up.

What is a good requirement?

A good requirement is clear, unambiguous, necessary, feasible, testable and traceable. It should also have a documented source, priority, status and preferably an acceptance criterion.

Why is traceability important?

Traceability makes it possible to understand where requirements come from, what they affect and how they are verified. It is especially important in complex projects, regulated industries and organizations where several teams work on the same product or system.

What is a requirements traceability matrix?

A requirements traceability matrix shows relationships between requirements and other objects, such as test cases, design, risks or regulatory sources. It helps the team see whether all requirements are covered and what is affected by changes.

Which tool is used for requirements management?

There are several tools for requirements management. In complex systems and software development, specialized tools such as IBM DOORS Next are often used, especially when the organization needs traceability, configuration management, review, reporting and support for large sets of requirements.

How is requirements management connected to testing?

Requirements describe what the solution must fulfill. Testing shows whether the solution actually fulfills the requirements. By linking requirements to test cases and test results, the organization can see test coverage, identify gaps and show what has been verified.

Does requirements management work in agile projects?

Yes. Agile projects also need requirements management, but it often happens more iteratively. Requirements can be expressed as epics, features, user stories and acceptance criteria. The important thing is to maintain sufficient structure, prioritization and traceability.

When do you need a requirements management tool?

You often need a requirements management tool when there are many requirements, when they change frequently, need version management, must be linked to tests and design or need to be followed up for audits, quality assurance and compliance.