Product · Change Management (CCB)
Controlled changes to confirmed requirements
Confirmed requirements represent agreed requirement content. When an agreed stakeholder requirement or system requirement needs to be changed or removed, that change should be handled as a decision — not as a normal edit. Qrendo req:ai supports this through structured change management, where proposed updates to confirmed requirements are collected, reviewed, decided, and documented before they are applied. Formal change management means that important changes are handled through a controlled process: the change is described, motivated, reviewed, decided, applied, and stored in history. A CCB, or Change Control Board, is a group or function responsible for reviewing proposed changes and deciding whether they should be accepted.
Audience: Change Control Board members, configuration managers, requirement leads, project managers, and quality owners responsible for controlled requirement changes.
Core concept
What should change.
Why the change is needed.
Which requirements are affected.
Who reviewed and decided.
When the decision was made.
Change package governance
How change management works
1. Create a change package Create a package with name, description, and motivation. 2. Add proposed requirement changes Collect one or more changes to confirmed stakeholder or system requirements. 3. Review and comment Review with relevant stakeholders and clarify before decision. 4. Finalize the decision Approved changes are applied and the finalized package is stored in project history.
Structured change packages
Related requirement updates are handled together, making it easier to understand the full scope and motivation of a change.
Review before implementation
Changes to confirmed requirements are reviewed and commented on before they are applied.
Formal decision point
Finalization creates a clear record of the decision, including who finalized it and when.
Complete change history
Completed change packages remain available in system history, showing what was decided, why, by whom, and when.
Clear overview at every step
Teams quickly see package name, motivation, affected requirements, and current status. The flow from proposal to decision is easy to follow, and history shows when decisions were made, by whom, and what was affected.
No uncontrolled changes to confirmed requirements
Agreed requirements can only be changed through a controlled decision process.
Clear governance for requirement changes
Important changes are reviewed, commented on, and decided before they take effect.
Stronger auditability and accountability
Every finalized change package becomes a traceable decision record in project history.