RDM Process
requirements definition and management (RDM) process: process for deciding what
changes to make to a product and when to make the changes, where 'change' means a set of modifications to the
functional design of the product in order to address one or more business problems or meet one or more business needs well
simply put, process for ensuring having agreement on a functional design change before making the change
A Simple, Effective, and Efficient RDM Process
To make GOOD REQUIREMENTS and make a great product, it is essential to follow a simple, effective, and efficient RDM process.
Below is a reference model of such a process:
![]() |
|---|
WholeTEAM RDM Process – Extended Notes
In WholeTEAM, the product team owns the product.
The whole product team—and only the product team— is responsible for requirements definition (RD.)
Business process owners (BPOs) and subject matter experts (SMEs) are a part of the product team.
The product's IT business analysts (ITBAs) and business product managers (BPMs) facilitate requirements.
The product's chief solutions architect (CSA) makes the final decisions on requirements. (In the absence of one, requirements-decision-making becomes an ad hoc — or even worse, a consensus — activity.)
The CSA is a member of the product functional design team, and of the change management core team (CMCT)—and is an IT role.
The CSA is a member of the product change control board (CCB) also.
The product change control board (CCB) owns the product vision.
The product CCB is a part of the product team—and is a Governance role.
The product CCB can demand or overrule any requirement.
The change management core team (CMCT) is the eyes of the product team.
The CMCT has representative from every unit of the product team.
The whole product team—and only the product team— is responsible for requirements definition (RD.)
Business process owners (BPOs) and subject matter experts (SMEs) are a part of the product team.
The product's IT business analysts (ITBAs) and business product managers (BPMs) facilitate requirements.
The product's chief solutions architect (CSA) makes the final decisions on requirements. (In the absence of one, requirements-decision-making becomes an ad hoc — or even worse, a consensus — activity.)
The CSA is a member of the product functional design team, and of the change management core team (CMCT)—and is an IT role.
The CSA is a member of the product change control board (CCB) also.
The product change control board (CCB) owns the product vision.
The product CCB is a part of the product team—and is a Governance role.
The product CCB can demand or overrule any requirement.
The change management core team (CMCT) is the eyes of the product team.
The CMCT has representative from every unit of the product team.



)