Funtional Specifications

8/2/2019 Funtional Specifications

1/6

http://wiki.sdn.sap.com/wiki/pages/viewpage.

action?pageId=33351

What Are Functional Specification in SAP? Added byRajesh Banka, last edited byAlon Mizrahion Nov 07, 2011 (view change)

To speak at macro level that is at projet manager or at senior levels. The Functional Spec

(Specification) which is a comprehensive document is created after the (SRS) Software

Requirements Document. It provides more details on selected items originally described in theSoftware Requirements Template. Elsewhre organizations combine these two documents into a

single document.

The Functional Specification describes the features of the desired functinality.. It describes the

product's features as seen by the stake holders,and contains the technical information and

the data needed for the design and developement.

The Functional Specification defines what the functionality will be of a particulat area that is to

be precise a transaction in SAP terminology.

The Functional Specification document to create a detailed design document that explains in

detail how the software will be designed and developed.

The functional specification translates the Software Requirements template into a technicaldescription which

a) Ensures that the product feature requirements are correctly understood before moving into the

next step, that is detchnical developement process.

b) Clearly and unambiguously provides all the information necessary for the technical

consultants to develop the objects.

At the consultant level the functional spects are preapred by functinal consultants on any

functionality for the purpose of getting the same functinality designed by the technical pepole as

most of the times the functionalities according to the requirements of the clients are not availableon ready made basis.

Let me throw some light on documentation which is prepared before and in a project:

1) Templates

2) Heat Analysis -3) Fit Gap or Gap Analysis
http://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=33351http://wiki.sdn.sap.com/wiki/display/~105vcvy8whttp://wiki.sdn.sap.com/wiki/display/~105vcvy8whttp://wiki.sdn.sap.com/wiki/display/~105vcvy8whttp://wiki.sdn.sap.com/wiki/display/~xxsi20thttp://wiki.sdn.sap.com/wiki/display/~xxsi20thttp://wiki.sdn.sap.com/wiki/display/~xxsi20thttp://wiki.sdn.sap.com/wiki/pages/diffpages.action?pageId=33351&originalId=257360973http://wiki.sdn.sap.com/wiki/pages/diffpages.action?pageId=33351&originalId=257360973http://wiki.sdn.sap.com/wiki/pages/diffpages.action?pageId=33351&originalId=257360973http://wiki.sdn.sap.com/wiki/pages/diffpages.action?pageId=33351&originalId=257360973http://wiki.sdn.sap.com/wiki/display/~xxsi20thttp://wiki.sdn.sap.com/wiki/display/~105vcvy8whttp://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=33351


2/6

4) Business Process Design

5) Business Process Model6) Business Change and Impact

7) Configuration Design, which is just 5 % of Total SAP- have different names -

8) Future Impact & Change Assessement

9) Functional Design (Module Wise)10) Risk Assessement

11) Process Metrics and Many More-- Which has impact on Business and its work flow

Note * This documents are preapared in Vanilla SAP Standards -- Things differ from one

implementation to another, and it always depends on the type of business which is opting for

SAP.

http://www.dataxstream.com/2010/04/writing-sap-functional-spec/

The Art of Writing an SAP Functional

Specification

April 20, 2010 ByMike Salvo5 Comments

Overview

I am currently working on an SAP implementation project that is just starting its realization

phase. One of my first tasks, as a member of the technical implementation team, is to review

completed functional specification documents for RICEF objects. These documents, written byfunctional subject matter experts, are supposed to detail business requirements that address gaps,

and which need to be incorporated into the system being implemented. The purpose of the

review is to make sure that the functional specification documents are complete, accurate, andcontain the approval signatures required to move on to the technical design phase.

In my career, I have had the pleasure of working with some first-rate functional analysts who

know how to draft an excellent functional specification document in a timely manner. It is this

type of performance that helps to move a project along in the right direction, on schedule, and

within budget. Likewise, I have had the not-so-pleasant task of working with not-so-first-ratefunctional analysts, who draft functional specification documents that are not clear, inaccurate,

and incomplete. The risks here are ultimately manifest as project delays and cost overruns.

The Good

A really good functional specification document contains enough detailed information about thebusiness process to enable a technical designer to use it as the foundation for drafting a complete
http://www.dataxstream.com/author/msalvo/http://www.dataxstream.com/author/msalvo/http://www.dataxstream.com/2010/04/writing-sap-functional-spec/#commentshttp://www.dataxstream.com/2010/04/writing-sap-functional-spec/#commentshttp://www.dataxstream.com/2010/04/writing-sap-functional-spec/#commentshttp://www.dataxstream.com/2010/04/writing-sap-functional-spec/#commentshttp://www.dataxstream.com/author/msalvo/


3/6

and accurate technical design document. The functional specification document should not only

highlight the presence of a gap, but should demonstrate how the business process, accompaniedby automation, will close the gap. This document must also indicate the abnormal processing

requirementswhat should happen when that report or interface does not run, what are the

recovery steps, how are key employees notified of the problem, etc. The content of a functional

specification document must be tuned to the flavor of the RICEF object that it isdescribing. Since they perform very different tasks, a report specification document should be

very much different from an interface, conversion, enhancement, or form functional specification

document. Using functional specification templates helps to insure the appropriate content foreach type of RICEF object.

and the Not-So-Good.

I am sometimes astonished by the sparse content that is actually offered up for review. We

need a report really does not tell me a whole lot about the business process that I am supposedto automate. Nor does it even hint at the report purpose, content, layout, user interface,

execution mode, authorization requirements, or error handling. And likewise, Build me aninterface does not even begin to describe the direction, payload content, mapping, frequency,error handling and recovery steps. It would be so wrong for me to attempt to build a technical

design on such meager functional definitions. One of my favorite cartoons shows a

development manager standing in front of rows of programmers saying You guys startcoding. Ill go and find out what they want.

I am further astonished by:

a) the project managers who apply pressure to accept inaccurate and incomplete functional

specification documents, to give the impression that the project is actually moving forward and

making meaningful progress.

b) the functional analysts who whine incessantly when their paltry functional specificationdocument is not accepted.

A functional specification document that does not meet expectations must be upgraded until itdoes. But bouncing a functional specification document back and forth like a ping pong ball

between the functional team and a technical reviewer is inefficient and wasteful. I find that the

best way to quickly firm up a weak functional specification document is to thoroughly researchall of the issues that I found in the document, formulate proposed solutions where possible, and

then schedule a face to face collaborative meeting with the functional analyst and the business

process owner(s). This type of collaboration can save hours, days, or even weeks of wastedping-pong posturing, and that is always best outcome for the project.

Off-Shore Technical Resources

This face-to-face quick resolution scenario typically cannot happen if you have an off-shoretechnical contingent in play. In this case, it is absolutely imperative that the functional
http://www.dataxstream.com/2010/03/sap-upgrades-offshore-resources/http://www.dataxstream.com/2010/03/sap-upgrades-offshore-resources/http://www.dataxstream.com/2010/03/sap-upgrades-offshore-resources/


4/6

specification document be most accurate and complete to mitigate the risk of excessive time

loss. Why is that?

Off-shore resources are sometimes time zone shifted eight or more hours ahead of where the

project is located. If a functional specification document is released for review, it will not be

analyzed until we have left for the day. If the off-shore reviewer has questions or raises issues,we will not see these questions or issues until the next day when we arrive at the project

site. When we respond to the questions or issues, the off-shore team will not see our responseuntil we have left for the day. And so on.

Under these conditions, a poorly written functional specification document with issues takesdays instead of hours to resolve. This leads to unnecessary project delays and cost overruns.

When One is Really Many

That 3PL interface, which was scoped and planned by the business process owners as a single

RICEF object named The 3PL Interface; and for which only one interface functionalspecification document is written, is actually many RICEF objects. We need to move purchase

orders, inventory receipts, advance ship notices, inventory picks, and cycle counts between the

two interfacing partners. Each of these represents a different payload, different mapping, istriggered by a different point in the business process, has separate error handling and recovery

procedures, and requires a separate RICEF development object.

That single enhancement functional specification document, which addresses all of SD pricing,

has the potential to extend into many different user exits. I just finished coding an ABAP proxy

that was functionally specified as one interface. In fact it was four. The requirement was tosearch the database for sales and invoice data starting with either an invoice number, sales order

number, customer name, or company name. Each of these search techniques required thedevelopment of a separate method. The only pieces of code that were shared among the four

search techniques were the input parameters and the output return table.

The point here is to make sure that the project planners understand the real complexity and effort

required on the development side, and to make sure that the project plan and budget reflectsthese more realistic metrics. This really goes a long way to stop everyone from wondering, Itsonly one interface! What is taking development so long?

Great Expectations

So what is a reasonable set of expectations for a really good functional specificationdocument? What is it that we are asking the business analyst to do?

First, let me describe what I do not expect. I do not expect a business analyst to write code, build

tables, design efficient database retrievals, or to decide that one BAPI, function module, class, or

IDOC is better than another.

Here is what I do expect:


5/6

A clear definition of a business process that is repeatable, and which actually works. As a pre-

automation test for data conversions, I always require the functional analyst to manually enterone of whatever, using the standard SAP transaction for which a conversion program is to be

built. Many times, they cant because the system is not configured correctly, the supporting data

is not present, or any number of other reasons which cause the transaction to fail. An interesting

observation is that there is much indignant huffing and puffing during this manual entry testprocess. But when the manual test fails, I simply remind them that I cannot automate a broken or

non-existent business process.

A clear definition of what should happen under abnormal or failure circumstances. This must

include error handling, notification, recovery and reprocessing steps.

A business process that can efficiently be automated. Requiring a search of sales order header

text for the phrase This is a red order is a very bad design for automation purposes. While

such a design is technically possible to build, it will certainly be inefficient at run time, and maynot always produce all of the red orders. This is because the key value is a free-form phrase that

can and will be misspelled, and abbreviated, along with countless other mutilations of the keyphrase This is a red order. There are much better business processes and technicalimplementations that will more efficiently and more accurately find all of the red orders in your

system.

An explanation of the need for development. Exactly what is the gap, and how will automating

the business process close the gap?

Screen shots from SAP transactions depicting data that is to be retrieved or stored. From the

screen shot in the transaction, I can usually determine the exact table and field in the SAP

database. Note that some business analysts are very adept at identifying the actual underlying

table and field name.

Clear and concise details with respect to data mappings, formulae, data transformations,conditional processing, etc. If I come to an intersection and it is unclear whether I should

continue to go straight, turn left, or turn right, then the functional specification document needs a

bit more detail behind it.

How to insure Consistency in Functional Specification Document Review

Design a separate functional specification document review checklist for each flavor of RICEF

object. Distribute these checklists to the functional specification writers so that they know what

the expectations are. Using a checklist will help to make sure that your review process isconsistent and accurate. Improve these checklists over time. My Form functional specification

checklist document now includes the following check:

Is it physically possible to print the specified content on the specified form using the specified

font style and size? Was an actual printed mock-up provided as proof?


6/6

- but only after I had received a functional spec for a form that required four inches of print

content on a one inch label. And somehow, the business analyst who wrote this particularrequest erroneously thought that it was my problem to solve. After all, writing code is

magic! Isnt it? In this case, I pushed back and insisted that an actual printed mock-up be

producedone that I would then agree to automate.

Summary

A good functional specification document will help tremendously in moving a project forward in

the right direction with minimal cost and risk. A poor functional specification document has

serious potential to cause project delays, and schedule and cost overruns. The best goal for theproject is to achieve a good functional specification document, using whatever means required.

Documents

Funtional Specifications