I am convinced that requirements management is the most essential part of any project or product development. Without a stable list of requirements the developers won’t know what to build, how to build it, or what to test.

Imagine this scenario: product development is already well under way for one year. Someone from marketing comes into the engineering office and ask about progress on feature X. The engineers realize that having feature X is quite fundamental. They claim it was never planned that the product should have this feature X. If they incorporated X, the entire product would need to be completely overhauled. Marketing on the other hand is convinced that this was a product requirement for the get-go. They claim to have told the engineering team about this feature more than a year ago. Who is right? Did marketing fail to communicate this feature request in the beginning? Did the engineers not consider feature X because it was too difficult to implement? Was feature X originally feature Y, but was changed during the discussions eight months ago?

Requirements management has been a mess in every single company I’ve worked for or consulted. Usually it took the form of several people working on an Excel spreadsheet and sending changes by email. You could easily spot the person in charge of consolidating these various versions of documents: it was the one pulling out their hair. Having many stakeholders communicate requirements in different ways is frustrating. Managing these requirements becomes even worse as the project progresses.

This is the reason why a while ago I started working on a web application for requirements management. The most important feature will be to have a central place for all requirements belonging to a project. Changes made to each requirement are logged in its history for improved traceability. Requirements can be linked to make dependencies visible. Each requirement can (and should) be linked with a test case.

Development is currently supported by my consulting company Transformatik GmbH. We nicknamed it “BrightRQ”. BrightRQ is heavily inspired by our extensive experience as project managers and requirement engineers for many companies in different industry sectors.

Roadmap / Planned Features

  • Multiple projects
  • Requirements
    • WYSIWYG editor for describing requirements
    • Category (user requirement, system, technical, …)
    • Attachments for Requirements (images, design documents, …)
    • Requirement type (functional, non-functional, security, …)
    • Requirement priority / importance
    • Linking requirements to visualize dependencies
    • Change history / traceability per requirement
    • Trash bin / restore for deleted requirements
    • View / filter requirements lists
    • Discuss requirements through comments
  • Testing
    • Add test cases to each requirement
    • Generate test lists and instructions for test engineers
  • General
    • Data export (e.g. PDF, Excel, Jira)
    • Risk management
    • Approval process
    • Email notifications on changes
    • Forward emails to BrightRQ to add new requirements
  • Security
    • Role-based access control (RBAC) - requirements engineer, auditor, …
    • Authentication with Active Directory / AzureAD
    • Two-factor Authentication (2FA)
    • Daily off-site backups