Change Requests

Change requests

Requirements change. That's not a failure, it's life. What hurts is change that happens silently: someone tweaks a rule in a meeting, nobody updates the requirement, and three weeks later the tests disagree with the code.

A change request (CR-0001) makes change visible and governed. It lives in the Changes tab of a Development.

The journey of a change

stateDiagram-v2
    direction LR
    [*] --> Submitted
    Submitted --> Triaged: Triage
    Triaged --> Accepted: Accept<br/>(rationale required)
    Triaged --> Rejected: Reject<br/>(rationale required)
    Accepted --> Scheduled: Schedule<br/>(target iteration required)
    Scheduled --> Implemented: Mark implemented
    Implemented --> Verified: Mark verified
    Verified --> Closed: Close
    Rejected --> Closed: Close
    Accepted --> Triaged: Back to triage
    Rejected --> Triaged: Back to triage

Loading

1. Submitted. Anyone describes the problem or the change, who asked for it and where it came from (a ticket, a meeting, an audit), with a priority and a severity.
2. Triaged. Someone has looked at it and it's ready for a decision.
3. Accepted or Rejected. The decision needs a written rationale. Studio records who decided and when.
4. Scheduled. An accepted change gets a target iteration.
5. Implemented → Verified → Closed.

Impact analysis

What a change affects is recorded as Impacts traces from the change request to the artifacts involved: "CR-0001 impacts BR-0001 (claims are filed within 90 days)". Inside a Development, only change requests can use the Impacts relation, which keeps its meaning crisp.

Readiness checks that every accepted change has an impact analysis and is scheduled, and the test management bridge checks that a change marked Verified really has passing tests behind it.

Where change requests show up

• On My work, in Change requests to decide, for the people who decide.
• On the Overview of the Development.
• On the pages of the artifacts they impact, through the trace.