You are on page 1of 17

ddadawd ggimage ggimage ggimage

frwet4ettear

ggimage

Functio nal Specifi cation


How to write effective SAP function al specs

As a SAP functional consultant, sometime early in the realization phase, for each RICEF item identified in the blue print phase, we have to write functional specs. This is very important especially when the ABAP development team is not on the project site but somewhere 8 hours or more ahead (like India).

The functional spec document is very important document as it captures:

1) The requirements (RICEF scope)

2) The design or how it should work

The requirements :

Typically a RICEF object is developed to cover a GAP in a standard SAP process. Therefore most often the object is require in order for a SAP process to work as the company intends to work. In the requirement section of the spec, the writer has to list all the things that the object should do. Also, sometimes is good to list what the RICEF object will not do just to set out the expectations. Also each requirement should be as detail as possible.

The design or how RICEF object should work

In this part of the spec, the writer has to define how the RICEF will work. Usually a flow chart should be drawn to show how the information will flow from the SAP process to the RICEF and also inside the RICEF.

If user interface elements (such as screens, menus) will be developed these should be mocked so that the developer will have all the information to design the UI element. Usually I mock up the screens in Excel but any other tool will work. Also if some new field needs to be added to a standard SAP screen, a screen shot of that screen will be a good starting point.

When I write my specs I try to give the developer as much information as needed so usually I put the table and fields from where the data needs to be selected. The best way to find where data is stored in SAP is to press F1 on a screen field and the press the technical details button (the button with a hummer as the icon). In most of the cases this will show you the field name and table where that information is stored.

Other things to consider.

Most of the specs are not done from the first iteration, they have to go multiple iterations before they are signed off by all partie involved. A brief change history and versioning works very good to keep track of all the stages the spec went through.

Add test scenarios to the spec. Define a list of at least few test scenarios that both the developer and the tester should perform to test the object.

If you have other piece of advice or tips about writing effective SAP RICEF functional specs, please feel free to comment on this article.

Functio nal Specifi cation


How to write effective SAP function al specs

As a SAP functional consultant, sometime early in the realization phase, for each RICEF item identified in the blue print phase, we have to write functional specs. This is very important especially when the ABAP development team is not on the project site but somewhere 8 hours or more ahead (like India).

The functional spec document is very important document as it captures: 1) The requirements (RICEF scope)

2) The design or how it should work

The requirements :

Typically a RICEF object is developed to cover a GAP in a standard SAP process. Therefore most often the object is require in order for a SAP process to work as the company intends to work. In the requirement section of the spec, the writer has to list all the things that the object should do. Also, sometimes is good to list what the RICEF object will not do just to set out the expectations. Also each requirement should be as detail as possible.

The design or how RICEF object should work

In this part of the spec, the writer has to define how the RICEF will work. Usually a flow chart should be drawn to show how the information will flow from the SAP process to the RICEF and also inside the RICEF.

If user interface elements (such as screens, menus) will be developed these should be mocked so that the developer will have all the information to design the UI element. Usually I mock up the screens in Excel but any other tool will work. Also if some new field needs to be added to a standard SAP screen, a screen shot of that screen will be a good starting point.

When I write my specs I try to give the developer as much information as needed so usually I put the table and fields from where the data needs to be selected. The best way to find where data is stored in SAP is to press F1 on a screen field and the press the technical details button (the button with a hummer as the icon). In most of the cases this will show you the field name and table where that information is stored.

Other things to consider.

Most of the specs are not done from the first iteration, they have to go multiple iterations before they are signed off by all partie involved. A brief change history and versioning works very good to keep track of all the stages the spec went through.

Add test scenarios to the spec. Define a list of at least few test scenarios that both the developer and the tester should perform to test the object.

If you have other piece of advice or tips about writing effective SAP RICEF functional specs, please feel free to comment on this article.

You might also like