The Art of Writing a Functional Specification Document

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 by functional 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, and contain 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-rate functional 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 the business process to enable a technical designer to use it as the foundation for drafting a complete 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, accompanied by automation, will close the gap. This document must also indicate the abnormal processing requirements what 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 is describing. 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 for each 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 supposed to 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 an interface 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 start coding. 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 specification document is not accepted. A functional specification document that does not meet expectations must be upgraded until it does. 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 research all 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 wasted ping-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-shore technical contingent in play. In this case, it is absolutely imperative that the functional 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 response until we have left for the day. And so on. Under these conditions, a poorly written functional specification document with issues takes days 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 functional specification 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, is triggered 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 to search 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 the development 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 reflects

these more realistic metrics. This really goes a long way to stop everyone from wondering, Its only one interface! What is taking development so long?

Great Expectations
So what is a reasonable set of expectations for a really good functional specification document? 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: A clear definition of a business process that is repeatable, and which actually works. As a preautomation test for data conversions, I always require the functional analyst to manually enter one 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 test process. 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 may not 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 key phrase This is a red order. There are much better business processes and technical implementations 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 is

consistent 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? - 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 particular request 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 produced one 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 the project is to achieve a good functional specification document, using whatever means required.

How To Cancel PO In SAP

In many cases we will encounter cases that will require a PO (Purchase Order) cancellation procedure, for example when a vendor is not able to fulfill the outstanding quantity stated in a PO, then PO cancellation procedure is needed. Because The SAP is not allow us to delete a PO and thats why we can only cancel the PO. Now there are 2 approches/best practices to cancel a PO. 1. Mark the PO as delivery completed, when we do this the PR will not be opened again. 2. Mark the deletion of PO line item, PR will be opened again and we can create a new PO based on this PR. Now heres how you do it. 1. Go To SAP Menu > Materials Management > Purchasing Order > Change

2. Input the PO number you want to change (Shift + f5). 3. Now there are 2 cases for PO Cancellation, the first one is we cancel the PO and also the

origin PR by clicking the Delivery Completed checkbox. The second case is we cancel the PO but we re open the PR, this is done by deleting the PO line item.

After you delete the line item, just click save. Popularity: 10% [?]

Table Relationship In SAP

Today I want to teach you how to find SAP table relationships, this is very useful for functional analyst to make a good program specification and also it can help ABAPer to look at the table relationships also. The TCODE well be using is SE11. 1. EXECUTE TCODE SE11 and enter the table name that you want to look at the relationship, in this tutorial I want to see table relationships between table EQUZ and ILOA, so I just type in the EQUZ table name and click on the display button.

2. Click on the Graphic button on the toolbar.

3. Next you will see the table relationship diagram, try to find the link between EQUZ table and the ILOA table and double click the link.

4. Now you can see that these two tables EQUZ and ILOA is linked by ILOAN key. Its pretty handy right?

Popularity: 1% [?]

Functional Spec for Sales Order

Asked by rakesh.usa | posted Apr 18, 2006 | Replies (1) I did not write functional spec before....any help...any help would be greately appreciated...atleast basic idea

In sales order when we give Sold-to party number and other details and hit enter....we get some pop-up windows One of them is for Partner address data. I have to add a field in that pop-up Now my requirement is I have to write functional spec for that How do I add that field...I mean what I have to put in the spec Is the pop-up window controlled by user exit....if so, do i have to say add this field in that user exit?? how to find what user exit is it? I clicked on that other field for structure name....But some fields have different strucutre names....if i have to add field in the structure , how do i know the name of the strucutre..... Do I have to give the new field name by myself or is it abapers work?? This spec should be very simple to the point... Thanks

Popular White Papers

The Big Book of SAP Upgrades More White papers 1 Reply Sign in or register for free to see all the answers on a single page

what is functional specs? Answer #1

Functional specification is a comprehensive document which describes the desired functionality. It contains technical information and data. It describes the scope,current functionality and desired functionality of a function/transaction.
Is This Answer Correct ?

1 Yes

0 No

Latha Re: what is functional specs? Answer #2

Hi, you can say functional spec is simply a prerequsite for creating a technical spec for any development created and forwarded by techno-functional guys or functional guys to the technical people(here thy create technical spec )and start developments and mainly functional spec compprise of .... What is the busineess seviority what is the impact on the business.. what approach is needed for development (to be more specific ) eg: if it is Zreports what type of reports (classical/interactive/alv) along with tables , fields should be furnished in the spec .... and finaly approval of spec is needed to proceed further for technical spec for development Hope this information is useful Regards..