Introduction

Standard Requirements Management is a new business scenario offered in SAP Solution Manager since release 7.2. To read more about this functionality in SPS 3, check out my overview blog:

Through the Looking Glass: Requirements Management in SAP Solution Manager 7.20, SPS 3

One of the missing functionalities I addressed in the blog above was that we have only a 1:1 relationship between a Business Requirement and an IT Requirement.

That can cause a restriction when a large Business Requirement should be split into multiple IT Requirements. The reasons for this might lie in different development groups cooperating because it is a cross functionality or it involves multiple landscape tracks. Another reason could be that parts should be delivered by different groups because some parts are delivered in the maintenance landscape while other parts are delivered in the landscape for new development for the next release. Thinking about it, you can come up with a lot of reasons.

 

Therefore, I am happy to announce that this functional restriction is now removed. In this blog, I will describe the delivered functionality in detail.

 

Creation of Multiple IT Requirements

When a Business Requirement reaches the status ‘Handed Over to IT’, the follow-up IT Requirement is created. This is still unchanged because before IT can decide whether multiple IT Requirements are needed, the situation first has to be checked. At some point, IT decides that they need another (or more) IT Requirements.

Technically, a copy is made of the IT requirement from the existing one as a follow-up and the follow-up relationship is adjusted so it becomes a follow-up to the business requirement.

This approach has some advantages compared to the creation of the IT Requirement from the Business Requirement as a follow-up. In the current case, when already multiple IT Requirements are present and filled with different content, it is possible to decide from which IT Requirement we should copy. This means you can choose your template. In the other case, the Business Requirement would be the only source to copy from.

 

The data copied is the same as when an IT Requirement is copied via the general copy document pushbutton.

 

The creation of an additional IT Requirement is possible provided not all IT Requirements have the status ‘Approval’. This includes the status ‘Define’, ‘Submitted for Validation’, ‘Being Checked’ and ‘Submitted for Approval’. Yet, the status ‘Rejected’    is excluded.

 

 

Status Flow

As we now have multiple IT Requirements belonging to one Business Requirement, the status flow itself will be affected. The good news is that we do not have added additional statuses.

 

So, what has changed…

Three Possibilities When One or Multiple IT Requirements Reach Status ‘Rejected’

 

With the 1:1 relationship of the Business and IT Requirement, when an IT Requirement has reached the status ‘Rejected’, the Business Requirement was automatically set to ‘Rejected By IT’. This has now changed.

 

The Requirements Manager now must inform the business department manually via the action “Report Business Are ‘Rejection Status’” that there is a showstopper. The Business Requirement is then set to ‘Rejected by IT’.

 

Then IT and Business need to discuss if there is a solution. There are three outcomes.

1.) Rework the Business Requirement Requested

If the Requirement is still valid and can be implemented in another way, the Business Requirement document is described again and go through the statuses ‘Define’, ‘Submitted for Validation’, ‘Being Checked’, and ‘Handed Over to IT’. All IT Requirements that have the status ‘Rejected’ are set to the status ‘Define’. Thus, the formal showstopper IT Requirement can be checked again and reach approval from IT.

 

2.) Detach and Close an IT Requirements

It is decided that the IT Requirement is out of scope but the other IT Requirements will be approved and implemented. In this case, it is possible to detach and close the out-of-scope IT Requirement from the Business Requirement. The rule is that at least one IT Requirement must stay as a follow-up document of the respective Business Requirement. That means, the last IT Requirement cannot be detached.

 

A detached IT Requirement is now a stand-alone requirement and can be closed or handled otherwise.

 

For the other follow-up IT Requirements, the process is unchanged.

 

3.) The Entire Business Requirement is Rejected

Business decides without the functionality contained in the IT Requirement rejected by IT that the whole Business Requirement is worthless and should not been implemented. In this case, the Business Requirement is set to ‘Rejected’ and all follow-up IT Requirements are also set to ‘Completed’.

The feedback from the testers was that the IT Requirement should differentiate between the normal ‘Completed’ and the ‘Completed’ via a Business Requirement rejection. This would result in a new status, which is currently being validated. If you as our customer already want to use this feature, it is already possible with the help of my earlier  blogs.

 

 

 

You can read about this in detail in the online documentation (www.help.sap.com) in a separate section. We as well added new status process flow maps. I recommend that you check it out.

 

Be aware that the ‘Postponed’ status is still available. So you can differentiate between a time (capacity) issue and a real showstopper.

 

New Parts in our Change Request Management Construction Kit

As customers adapt the process to their needs, Requirements and Change Request Management, which both are built on the ChaRM Framework are highly flexible.

 

So, with SAP Solution Manager 7.2 SPS 5, we bring in two additional pieces.

 

PPF action implementation HF_REPLACE

The PPF action SMIR_CREATE_ADDITIONAL_ITR uses this BadI implementation. It is the piece that creates the additional IT Requirement.

 

In the PPF action definition, the PPF action container element ‘TARGET_PROC_TYPE’ contains the information about the transaction type which one?? should be created and reassigned.

 

So, if you enter, for example, a request for change transaction type (and the prerequisites such as the copy control is customized), you can use this functionality to create a request for change from an IT Requirement (or another source) as a follow-up and reassign it to its predecessor.

 

Change Request Management Action PREDOC_CUT

This new Change Request Management Framework action does the trick with detaching the IT Requirement from a Business Requirement. It can be used by a PPF action and needs the following PPF container elements:

• ACTION_ID: for triggering the ChaRM action ‘PREDOC_CUT’ which deletes the predecessor docflow
• SET_PREDOC_TRIGGER: which defines which status is used for the document to check if a SET_PREDOC is triggered. In the standard case, the status E0006 (Approved) of the IT requirement is used which checks if the Business Requirement might be set to ‘Approved by IT’ in case all other IT Requirements are already ‘Appoved’.
• USER_STATUS for setting the decoupled IT Requirement to the status ‘Completed’ after decoupling.

In general, this functionality should also work for other Change Request Management and Requirements Management documents. For instance, decoupling an urgent change from a request for change. If you have an interesting use case, please share it with me.

Specify Required Follow-Up Status

I described the functionality to set the status of a successor document from their predecessor documents via the Change Request Management Framework action ‘SET_SUCCDOC’ in the overview blog (see link above).

 

What is new with SPS 5 is that you can customize a required status that the successor document needs to trigger the status change. Otherwise, the successor document stays in the original status.

 

 

This might be interesting for special customer use cases and is useful to disprupt possible SET_SUCCDOC and SET_PREDOC endless loops. Endless loop means the predecessor reaches a status triggered by the successor. In return, this triggers a successor again to set a status, which triggers the predecessor again.

 

In the standard solution, the functionality is used when a reworked Business Requirement is set to ‘Handed Over to IT’ again. Only IT Requirements that have the required follow-up status ‘Rejected’ are set to the status ‘Define’ again.

Enabling Already Copied Business and IT Requirements for the Multiple IT Requirements Functionality

You are already using Requirements Management prior to SPS 5 and would like to use the 1:N functionality? Check out Solution Manager Setup. There you find a guided procedure to help you with the delta Customizing.

If you execute the Solman Setup activity, a new mode starts, which includes all Customizing (IMG) activities you should look at.

Additionally, there is a link to Knowledge Based Article (KBA) 2404488. It describes the procedure in detail with screenshots, translated. I don’t want to go too much into detail here because I think the description is good.

 

I hope, the blog helps you understand this new functionality and motivates you to try it out.

 

In case you find errors in this blog or have questions or feedback, contact me.

 

Thank you, Michael