Requirements Lifecycle Management

About Requirements Lifecycle Management

DLM gets your documents under control; RLM turns what they say into commitments you can track. Built on everything in DLM, RLM keeps every requirement in one database as the master copy. It can start from your RFP, an RTM workbook, or the “shall” and “must” sentences of a statement of work, which become draft requirements to accept or reject. From there each requirement is traced to its epics, functional specs, user stories, business rules, designs, subsystems, reviews and the documents behind it. Teams review requirements in structured sessions with comments, actions and minutes, and track each one’s status from New to Approved. A SMART quality check and data checks catch gaps early (no design, no test, no owner), and an Accepted requirement can’t change without a reason, a source and a Change Order number. You can merge, split, baseline and compare the whole RTM, export it in your client’s layout, and follow any requirement to be told when it changes. Where DLM answers “which document is current and approved?”, RLM answers “what did we promise, where is it designed, who signed it off, and what changed?” It’s built for programmes delivering against a contract: Business Analysts, RTM Managers, Project Managers, Workstream Leads and clients’ reviewers on large, multi-vendor projects (tolling, transport, public-sector systems) where requirements number in the thousands and every change has to be defended.

What it does

Create and manage. Set up a client and create its base RTM from the RFP, or import an RTM workbook or a statement of work (its “shall” and “must” sentences become draft requirements). Search every field, with * as a wildcard; edit in place, in a Standard view or an Advanced grid; page through any list; merge two requirements or split one, with proposals across the whole RTM; keep a glossary of terms; see the data checks; and baseline the whole RTM as a read-only copy. An Accepted requirement’s text changes only with a reason, a source and a Change Order number.

Design and review. Map requirements to programme epics and functional specs by drag and drop, allocate subsystems, and add business processes, functional specs and documents, with draw.io designs (a PDF becomes an editable diagram). Review sessions run as a four-step wizard with slides built from an epic and its features, comments on every item, actions, close requests by email and minutes in Excel.

Plan and implement. PI and sprint plan, a PI calendar with a Programme view, the release train, Planned Deployment and Workstreams Affected per requirement, and the PI board for Admins. Every website change is traced to its requirements, each requirement records the release each subsystem shipped it in, and Jira tickets link to the requirements they name.

Validate and report. Test cases, a test matrix and coverage per requirement; status charts on tabbed, arrangeable reports; the RTM export to Excel, PDF or Word in a layout an Admin sets, with a new version and its revision history, which imports back as it is; and alerts by message, email or Microsoft Teams when something you follow changes.

Who it is for

Programme teams and their clients: Admins, Business Analysts, RTM Managers, Project Managers, Workstream Leads, Testers and Test Managers, Sales (who set up a new customer and its base RTM) and Legal, with Clients and Client consultants viewing the RTM and joining reviews. Each person opens only the clients they are given.

At a glance

• Clients: one RTM per client, each in its own database.
• Hosting: a managed cloud service with a PostgreSQL database; sign-in by email, with roles kept by Admins.
• Integrations: Confluence Cloud, Jira Cloud, Microsoft Teams, email notifications, the client’s website release notes, a document app with its own revocable key, and an optional AI quality check of a requirement.
• Quality and releases: over 1,600 automated tests run in parallel before every release; small releases, often several a day.