Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Requirements Rejection

Use rejection states to prevent delivery work on out-of-scope requirements.

Overview

Not all requirements should be delivered. A clear rejection workflow prevents work on out-of-scope items.

Key Concepts

  • Rejection reason: why the requirement is not being delivered

  • Status semantics: difference between rejected, deferred, and obsolete

  • Downstream impact: tasks and tests that must be closed or updated

How It’s Used

Use rejection when scope is explicitly removed. Use deferral when scope remains valid but not in the current phase.

Benefits

  • Reduced wasted effort

  • Clearer audit trail for scope decisions

  • Cleaner reporting by excluding non-deliverable scope

Setup Steps

1

Confirm decision

Record decision rationale in comments. Link supporting artifacts when available.

2

Set requirement status

Set status to a rejected or out-of-scope state. Use standardized status meanings across Projects.

3

Close downstream work

Close or re-scope linked tasks and tests. Remove assignments that would continue delivery work.

Best Practices

  • Avoid deleting rejected requirements.

  • Prefer clear status states for reporting.

  • Use a consistent set of rejection reasons in an internal SOP.

Summary

Requirements Rejection prevents delivery work on removed scope. Status and downstream cleanup keep reporting accurate.

Related:

Last updated