News From The Developer: Requirements Management in SAP Solution Manager Allows Now for Business With Mulitple IT Requirements
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 diﬀerent 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 diﬀerent 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 ﬁlled with diﬀerent 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 ‘Deﬁne’, ‘Submitted for Validation’, ‘Being Checked’ and ‘Submitted for Approval’. Yet, the status ‘Rejected’ is excluded.
As we now have multiple IT Requirements belonging to one Business Requirement, the status ﬂow 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 ‘Deﬁne’, ‘Submitted for Validation’, ‘Being Checked’, and ‘Handed Over to IT’. All IT Requirements that have the status ‘Rejected’ are set to the status ‘Deﬁne’. 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 diﬀerentiate 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 ﬂow maps. I recommend that you check it out.
Be aware that the ‘Postponed’ status is still available. So you can diﬀerentiate 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 ﬂexible.
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 deﬁnition, 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 ‘Deﬁne’ 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 ﬁnd errors in this blog or have questions or feedback, contact me.
Thank you, Michael
Nice blog. More informative.
I have some queries. I have implemented Requirement management in 7.2 SP04 and linked to SOLDOC solution. but i am not able to find filter option to get the requirement management assignment details in SOLDOC List view.
Whether this filter or report option available in SP05? or will deliver in future SP?
These blogs on requirements management are really great and helpful.
However, considering requirements are also on ChaRM framework, we are still looking for a clear definition/ direction to when should one use requirements management and request for change. Do you have some pointers there?
the difference between IT requirement and request for change is more from ITIL definition and the source where they originate from.
Request for Change should be used for maintenance issue/projects, IT requirements are coming from the innovation side.
The difference in the documents is mainly in these points:
1.) The approval concept. The request for change used the approval procedure and the approval is given mainly by the change manager. The change documents (e.g. urgent change) which are created are clear upfront to the approval. The IT requirement has a two-step approval as it is something more like a quote and order process. The business needs something, IT says, we can do it like this, is this fine? And business says, okay, that is okay. Start! When this is done from a status flow, there is no more checking which types and how much changes are created. You are implementing project based and it is clear, it is wanted and you need to do changes.
The IT requirement is a follow up from a business requirement, so a new innovation. Mostly tight to an ITPPM project and staffed. And it might be a lot bigger than a request for change. That's why we introduced an 1 to N relationship from Business to IT requirement, so you can split up the big business requirement into several IT requirements. Which might affect different departments and development teams. There is as well a more enhanced status flow to handle IT requirements which cannot be implemented (decoupling from the business requirement, reworking the business requirement to a smaller scope or cancelling everything).
Hope that makes things a bit more clear,
Thank you Michael 🙂
You should go to Reports (from global service menu) –>And then select “Related Documents” to pull the required list.
Is there any standard report where it can list the selected Bus Requirement and their related IT Requirements and the related Change Doc's?
Also in the search of a BR, is there any option to show in the result list that the related IR number as well? And vise versa?