Bringing Structure and Guidance to Requirement and Approval Statuses in SAP Cloud ALM

[mustameerahmed_khan]

SAP Cloud ALM continues to evolve, and the latest enhancement to the Requirements application introduces an important shift in how requirement statuses and approval states interact. Previously, users could freely update both approval and requirement statuses without restrictions, which offered flexibility but lacked process guidance. With the new capabilities, SAP Cloud ALM introduces structure, ensures alignment between approval and requirement statuses, and improves governance by controlling when requirement descriptions can be edited.

What Has Changed?

Conditional Status Selections Based on Approval State

In the past, any requirement status could be selected regardless of the approval state. This unrestricted flexibility is now replaced by a more guided approach, where available requirement statuses are determined by the requirement’s approval state. This ensures a clearer lifecycle and better control.

Approval and Requirement Status Mapping

To clearly understand how approval and requirement statuses now interact, refer to the table below:

 

Approval State	Requirement Status
No Approval Required	“In approval” no longer visible in dropdown Selectable values are: • In Refinement • In Planning • In Realization • In Testing • Successfully Tested • Blocked • Confirmed • Not Planned This state is best used for requirements that do not need a formal approval workflow.
Ready for Approval	The system sets the status to "In Approval". No other status than “In approval” can be set until requirement is either: • Approved • Rejected • Reverted to “No Approval Required” This enforces discipline during the approval process and locks the requirement in a pending state.
Approved	The system sets the status to "In Planning" and allows you to change to: • In Realization • In Testing • Successfully Tested • Blocked • Confirmed • Not Planned Once a requirement is approved, it follows a logical progression through implementation phases.
Rejected	The system sets the status to "Not Planned" The requirement is effectively paused and marked as not moving forward.
From “Ready for Approval” to Not Assigned	(1) Requirement was in status “In Approval” (2) Approval state changed (e.g., to “No Approval Required”) (3) System sets status to "In Refinement"

Trail and Reset Capabilities

• All changes to statuses and approval states are logged with timestamp and user information in the Requirement History.

  

• Project Administrators can reset approved or rejected requirements to "Not Assigned", and the system will reset the status to "In Refinement". This gives flexibility when re-evaluation is needed without losing historical traceability.

Locking of Description Fields

Another major improvement is the locking of requirement descriptions in certain states to ensure clarity and integrity of the content:

• Descriptions are locked when:

  • Approval State = No Approval Required or Rejected

  • Requirement Status = In Approval, Successfully Tested, or Confirmed

This prevents changes to critical requirements once they’ve reached a significant phase or decision point in the workflow.

 

Guidance Messages for Users

To support users, the system now provides real-time messages and hints when attempting status or approval changes. These messages:

• Indicate the next possible or required action.

• Explain why a status is locked or unavailable.

• Help prevent invalid transitions.

New status "In Planning" in Requirements

The "In Planning" status has been introduced to address a common scenario in agile and hybrid project execution: teams don’t typically start working on a requirement immediately after it is approved.

Why This Status Was Needed

• Previously, once a requirement was approved, it moved directly to statuses like "In Realization".

• However, this caused confusion—since no work may have started yet, setting a requirement to “In Realization” prematurely was misleading.

• The option “Not Planned” couldn’t be used either, as it is mapped to “Not Relevant” and implies the requirement is no longer considered for implementation.

Purpose of "In Planning"

To solve this, the "In Planning" status was introduced:

• It acts as a holding state for all approved requirements.

• It becomes the default status once a requirement is approved.

• It allows teams to filter and review all approved requirements during planning sessions, such as sprint planning or wave definition.

• From here, requirements can be prioritized and assigned to sprints for execution.

Only when the team actively begins working on the requirement does the status move forward to "In Realization".

Typical Activities in status "In Planning".

• Assign effort estimates and responsible teams.

• Link the requirement to a sprint or release.

• Break down into user stories or implementation tasks.

• Review dependencies and prepare for realization.

This structured intermediate step adds clarity and avoids confusion in status tracking, particularly in complex or large-scale projects.

Conclusion :

These enhancements bring much-needed structure and governance to requirements management in SAP Cloud ALM. By aligning requirement status transitions with approval states and locking critical information at the right times, the system now supports a more disciplined and auditable requirements lifecycle.

Whether you're refining your backlog or managing complex implementation phases, these updates helps ensure that your team follows a clear and consistent process from ideation to confirmation.

More Improvements are planned in the direction of bringing consistency, traceability, and clarity in requirement management. Stay tuned for more updates and guidance.