Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Daniel_Enderli
Active Participant

Introduction


Requirements engineering is the process of defining, documenting, and maintaining requirements. It's very common and good practice to use requirements engineering for system- and software engineering. There are various frameworks and organizations which helped to create standardization and providing guidelines for requirements engineering. One of these is IREB.org

With this blog post I would like to give you some ideas, tools and concrete examples how to use requirements engineering for SAP solutions.

 

In a nutshell


The process "From requirements to deploy" is starting with the recording of requirements.

It is highly recommended to use a central tool for this, because you lose overview for a large number of requirements. One possible solution specially for SAP is to use SAP Solution Manager with Focused Build.

Once you have filled you product backlog with requirements you have to prioritize them and bring them in an order. Released requirements moves over to the development pipeline.

The better the requirements are described, the easier is it to implement and test them. It is better to invest more effort at the beginning and benefit from it later.

“What the wise do in the beginning, fools do in the end.” (Warren Buffett)


 

SAP Activate


Many SAP projects start using SAP Activate, because it is the methodology recommended by SAP.

SAP Activate structures the project approach in multiple phases. In the "Explore" phase you will collect your requirements.


Source: SAP

SAP Activate includes several accelerators and tools to speed up the implementation.
My favourites are:

  • SAP Solution Manager: To have a single source of truth for your Application Lifecycle Management.

  • SAP Best Practice: To build up your process structure and not to start from scratch.

  • Focused Build: To manage your backlog and to control the development pipeline.

  • Incremental development

  • SAFe/Scrum or even Waterfall: To have a project approach followed by a common methodology adopted for SAP.


Here's a nice overview about Mastering SAP Activate:


Source: SAP

 

Fit/Gap or Fit-to-Standard


In the area of SAP we often use the term "Fit/Gap" or "Fit-to-Standard" to define the project scope and identify requirements for business processes and functions which have to be implemented.


 

Requirements in Focused Build


Within Focused Build you have a simple UI for recording your requirements. A great added value is that you can create the requirements based on the process structure. That helps to identify which  requirements belongs to which processes.

Recommendations for requirements:

  • They are clearly described

  • They are precise for a specific requirement

  • They are testable (functional or non functional)

  • They have acceptance criterias defined


Also have a look at the "INVEST criterias", they provide a useful Definition of Ready which can be applied to requirements in the product backlog.



 

Product backlog with requirements


In the product backlog or simply said the collection of requirements you can now go further on and check, enrich, prioritize and release your requirements for development.



Effort estimation / Story points


In order to estimate the effort and value for the implementation of requirements, there are also many proven scales. Some of it are:

  • Story points

  • Number of hours or person days

  • T-shirt sizes S, M, L, XL


Have a look at Planning Poker which is a way to estimate the effort.

In order to prioritize the backlog, a periodic review of all recorded requirements in the backlog is necessary. You need to:

  • Decide whether the requirement is still valid

  • Prioritize the requirements

  • Identify must have / should have features

  • Determine value points

  • Determine effort points


 

Conclusion


As you see, it is worth considering to define from the beginning how the requirements must be recorded, collected, prioritized, reviewed and released. This improves significantly the quality of the developments that were realized.

I hope I was able to give you some ideas and helpful resources with this blog post.

Happy engineering!
Labels in this area