How to Allocate Software Requirements to Implementation

 Sep 11, 2026 Hana Jirsova tips share

Learn how to allocate software requirements to implementation source code, architecture or design model using ReqView.

In safety-critical and regulated industries, maintaining bidirectional traceability between software requirements and source code is not optional. It is mandatory requirement for standards like ISO 26262, DO-178C, IEC 62304, and EN 50128. Establishing robust traceability ensures that every requirement is implemented, every piece of code has a clear purpose, and testing covers all critical functionality.

In practice, there are two complementary approaches to establish traceability between software requirements and source code:

1. Allocate software requirements to implementation. Link each software requirement to software architecture elements, functional model elements, or source-code elements that implements it. This helps with answering questions:

   • “Where is this software requirement implemented?”
   • “Are all software requirements implemented?”
   • “What will be the impact on the implementation if this software requirement changes?”
   • “What is the purpose of the implementation?”

2. Trace requirement changes through version control. Reference requirement IDs or issue IDs from Git commits and pull requests so that reviewers can understand why the code changed and which requirement version or issue initiated the change. This helps with answering questions:

   • “Why did this implementation change?”
   • “Who has approved the change?”

Mature projects normally use both approaches. In this post, we explain the first approach and demonstrate how to reference requirements from software source code or the architecture or design model depending on your software development process.

Allocate Software Requirements to Source Code

When you do not maintain architecture or functional model and write the source code manually, you can reference software requirements directly from source-code docstrings or comments at the scope of software packages, modules, classes, functions, methods, or other implementation units.

This approach provides precise, line-level evidence of implementation that easily survives refactoring because developers maintain traceability directly in the codebase.

ReqView supports the following workflow leveraging its open file format and custom integration with 3rd party tools for documentation generation:

1. Manage software requirements in ReqView.
2. Implement requirements and reference ReqView software requirement IDs in source code.
3. Generate software source code documentation including URL links from source code to ReqView requirements using a documentation generation tool, such as Doxygen, JavaDoc, or MkDocs.
4. Convert software source code documentation into ReqView documents preserving traceability links from source code to requirements.
5. Review software requirements allocation to source code in ReqView.

This approach is lightweight and can be introduced incrementally. Its main limitation is maintenance: links attached to low-level functions or files may need to be updated whenever the code is refactored.

Example ReqView Integration with Doxygen

As an example, let us demonstrate how to use ReqView and Doxygen open-source tool to generate documentation of C++ library NumCpp, which implements fundamental mathematical functions for scientific computing using header-only C++ templates.

Download and Install Example:

Clone the Git repository ReqView > Blog > Example ReqView Integration With Doxygen from GitLab:

$ git clone https://gitlab.com/reqview/blog/reqview-doxygen-integration-example.git

Or, download the content of the repository: reqview-doxygen-integration-example-main.zip.

The repository contains the following directories:

• numcpp – the source code of NumCpp v2.16.1,
• reqview – the ReqView requirements project, and
• scripts – supporting scripts generated by Claude AI to make the documentation generation easier.

If you want to try out the example, initialize the project tools first:

1. Download and install Doxygen.

2. Download and install CMake.

3. Download and install the required NPM libraries used by the scripts in the scripts directory.

   $ npm install

Now, you can iteratively repeat each step of the workflow introduced earlier.

Step 1. Manage Software Requirements in ReqView:

In ReqView, open the project NumCpp from the Project Folder ./reqview. The project contains:

• Document SRS – Software Requirements Specification, which contains section 2.2.1 Random with few example software requirements SRS-33, SRS-34, and SRS-35, which will be referenced from source code.

• Document IMPL, which is a placeholder for source code documentation generated from source code in later steps.

• Configuration of Implementation traceability link type for tracing software requirements allocation to source code.

Optionally, open the document NumCpp/SRS and add few more requirements:

Step 2. Reference Software Requirements From Source Code:

Add requirements references in Doxygen comments of the implemented NumCpp class, function, or other source element:

//============================================================================
// Method Description:
/// Return random integer from low (inclusive) to high (exclusive),
/// with the given shape. If no high value is input then the range will
/// go from [0, low).
///
/// \reqview{SRS-33}
///
/// NumPy Reference:
/// https://docs.scipy.org/doc/numpy/reference/generated/numpy.random.randint.html#numpy.random.randint
///
/// @param generator: instance of a random number generator
/// @param inLow
/// @param inHigh default 0.
/// @return NdArray
///
template<typename dtype, typename GeneratorType = std::mt19937>
dtype randInt(GeneratorType& generator, dtype inLow, dtype inHigh = 0)
 // ...

You can also reference multiple requirements:

/**
* \reqview{SRS-33}
* \reqview{SRS-34}
*/

Note, that we updated the Doxygen configuration file ./numcpp/docs/doxygen/Doxyfile.in to define alias \reqview simplifying references to ReqView requirements:

ALIASES = reqview{1}="ReqView Reference: <a href=\"reqview:open?projectId=NumCpp#\1\">NumCpp/\1</a>"

With the alias, you can use just requirement ID (e.g., \reqview{SRS-7}) as the requirements reference and Doxygen renders the annotation as a clickable link: “ReqView Reference: NumCpp/SRS-33”. Without the alias, you need to use the HTML element <a> with full ReqView URL (e.g. <a href="reqview:open?projectId=NumCpp#SRS-7">NumCpp/SRS-7</a>).

Step 3. Generate Doxygen Source Code Documentation:

To generate Doxygen HTML and XML documentation of the NumCpp library, run:

$ npm run build:doxygen

This script will run cmake and doxygen commands, which create the HTML and XML documentation in directory ./numcpp/docs/doxygen.

You can deploy the HTML documentation from the directory ./numcpp/docs/doxygen/html to a web server to make it available online. In our example Git repository, we have set up a GitLab CI script to build and deploy the NumCpp HTML documentation to GitLab Pages automatically.

For instance, the HTML documentation of NumCpp function nc::random::randInt contains a ReqView reference to the requirement NumCpp/SRS-33:

To open the referenced requirement in ReqView, click on the URL link NumCpp/SRS-33 in ReqView Reference.

Note, that we updated the Doxygen configuration file ./numcpp/docs/doxygen/Doxyfile.in to enable generation of XML documentation in directory ./numcpp/docs/doxygen/xml:

GENERATE_XML = YES

Step 4. Convert Doxygen XML to ReqView Document:

To convert the XML documentation generated by Doxygen into the ReqView document file ./reqview/documents/IMPL.json, run:

$ npm run build:reqview

This will run the JS script ./scripts/convert-doxygen-to-reqview.js, which parses Doxygen XML files, reconstructs the source code tree, and updates the ReqView file ./reqview/documents/IMPL.json.

In ReqView, open the document NumCpp/IMPL generated from the Doxygen XML files:

You can to browse the source code documentation and navigate to Doxygen HTML documentation by clicking on links in the column Doxygen. The Links column displays Implementation links from NumCpp source code to software requirements in the document NumCpp/SRS.

Step 5. Review Software Requirements Allocation to Source Code in ReqView:

To review the allocation of software requirements in ReqView, open the document NumCpp/SRS, switch to the table view Requirements Allocation, and check the column Source Code displaying navigable URL links to Doxygen HTML documentation:

You can easily navigate between requirements in the ReqView document NumCpp/SRS and Doxygen HTML documentation of NumCpp source code in both directions using the URL links.

Allocate Software Requirements to Model

In a model-based development workflow, software requirements are usually allocated to software architecture or functional model elements rather than directly to source-code files. The model is the authoritative design representation, while source code is a derived artifact.

This level of traceability is more stable than linking each requirement directly to source code files. However, it does not eliminate model maintenance. When source code is refactored, the model need to be updated as well so that it still represents the actual implementation.

ReqView integrates with Sparx Enterprise Architect (EA) to support this workflow:

1. Capture and manage software requirements in the ReqView document SRS:

   

2. Export software requirements from the ReqView document SRS to EA model:

   

3. Model software architecture and design in EA using SysML or UML diagrams and allocate software requirements to model elements using dependency links with the stereotype <<trace>>:

   

4. Import the selected part of EA model to a dedicated ReqView document describing software design:

   

5. Trace user needs to software requirements and their implementation in ReqView:

   

For more information, see Requirements Management for Sparx Enterprise Architect MBSE Tool.

Identify Not Allocated Software Requirements

Once the traceability between software requirements and implementation is established and maintained, you can use ReqView powerful traceability features to check implementation completeness and estimate impact of requirement changes.

To identify not allocated software requirements, open the SRS document and add the column Implemented By displaying incoming Implementation links using the Traceability Column Wizard. When you browse the SRS document, you can easily recognize not allocated requirements because they have this column empty.

To list all not allocated requirements only, use a filtered table view with condition:  Type: Functional Requirement  NOT Is implemented by.

Because ReqView generates traceability views and reports from maintained links, you do not need to maintain a separate spreadsheet. You can simply inspect gaps in requirements allocation and do impact analysis using live traceability matrix in ReqView. Or, you can export traceability reports to Word, Excel, PDF, HTML, or CSV formats for external reviewers.

Conclusion

In ReqView, you can easily manage traceability between software requirements and their implementation. This greatly helps you to answer questions such as “Are all software requirements implemented?” or “What impact will a requirement change have on the implementation?”.

For manually written software without a maintained model, you can integrate ReqView with a source code documentation tool and reference requirement IDs in source code comments. Using the NumCpp C++ library as a concrete example, we demonstrated how to implement a custom script that maintains bidirectional traceability between software requirements in ReqView and HTML source code documentation generated by Doxygen.

For model-based development, we illustrated how the ReqView integration with Sparx Enterprise Architect can be used to allocate software requirements to elements in a UML or SysML model.