What are Functional Specifications?

Functional specifications (functional specs), in the end, are the blueprint for how
you want a particular report and transaction to look and work. It details what the
report will do, how a user will interact with it, and what it will look like. By creating a
blueprint of the report or transaction first, time and productivity are saved during
the development stage because the programmers can program instead of also
working out the logic of the user-experience. It will also enable you to manage the
expectations of your clients or management, as they will know exactly what to
expect.

A key benefit of writing up a Functional Spec is in streamlining the development

process. The developer working from the spec has, ideally, all of their questions
answered about the report or transaction and can start building it. And since this is
a spec that was approved by the client, they are building nothing less than what the
client is expecting. There should be nothing left to guess or interpret when the spec
is completed.

Functional Specification
A functional specification (or sometimes functional specifications) is a formal
document used to describe in detail for software developers a product's intended
capabilities, appearance, and interactions with users. The functional specification is
a kind of guideline and continuing reference point as the developers write the
programming code. (At least one major product development group used a "Write
the manual first" approach. Before the product existed, they wrote the user's guide
for a word processing system, then declared that the user's guide was the
functional specification. The developers were challenged to create a product that
matched what the user's guide described.) Typically, the functional specification for
an application program with a series of interactive windows and dialogs with a user
would show the visual appearance of the user interface and describe each of the
possible user input actions and the program response actions. A functional
specification may also contain formal descriptions of user tasks, dependencies on
other products, and usability criteria. Many companies have a guide for developers
that describes what topics any product's functional specification should contain.
For a sense of where the functional specification fits into the development process,
here are a typical series of steps in developing a software product:

Requirements:
This is a formal statement of what the product planners informed by their
knowledge of the marketplace and specific input from existing or potential
customers believe is needed for a new product or a new version of an existing
product. Requirements are usually expressed in terms of narrative statements and
in a relatively general way.
Objectives: Objectives are written by product designers in response to the
Requirements. They describe in a more specific way what the product will look like.
Objectives may describe architectures, protocols, and standards to which the
product will conform. Measurable objectives are those that set some criteria by
which the end product can be judged. Measurability can be in terms of some index
of customer satisfaction or in terms of capabilities and task times. Objectives must
recognize time and resource constraints. The development schedule is often part or
a corollary of the Objectives.
Functional specification.: The functional specification (usually functional spec or just
spec for short) is the formal response to the objectives. It describes all external user
and programming interfaces that the product must support.
Design change requests: Throughout the development process, as the need for
change to the functional specification is recognized, a formal change is described in
a design change request.

Logic Specification:
The structure of the programming (for example, major groups of code modules that
support a similar function), individual code modules and their relationships, and the
data parameters that they pass to each other may be described in a formal
document called a logic specification. The logic specification describes internal
interfaces and is for use only by the developers, testers, and, later, to some extent,
the programmers that service the product and provide code fixes to the field.

User documentation:
In general, all of the preceding documents (except the logic specification) are used
as source material for the technical manuals and online information (such as help
pages) that are prepared for the product's users.
Test plan: Most development groups have a formal test plan that describes test
cases that will exercise the programming that is written. Testing is done at the
module (or unit) level, at the component level, and at the system level in context
with other products. This can be thought of as alpha testing. The plan may also
allow for beta test. Some companies provide an early version of the product to a
selected group of customers for testing in a "real world" situation.

The Final Product:

Ideally, the final product is a complete implementation of the functional
specification and design change requests, some of which may result from formal
testing and beta testing. The cycle is then repeated for the next version of the
product, beginning with a new Requirements statement, which ideally uses
feedback from customers about the current product to determine what customers
need or want next.
Most software makers adhere to a formal development process similar to the one
described above. The hardware development process is similar but includes some
additional considerations for the outsourcing of parts and verification of the
manufacturing process itself.

Re: What are functional specs? can anyone give a eg. of a functional specification pls.
Answer
#1
Functional spec refers to the actual requirement from the
customer. This gives the actual scope.

Is This Answer Correct ?

5 Yes 1 No
0
Kae
Re: What are functional specs? can anyone give a eg. of a functional specification pls.
Answer
#2
Functional specifications are used to develop reports .FS
contains tables,fields,selection criterias, output list
etc...

What Are Functional Specification in SAP?

Link to this Page Link Tiny Link Wiki Markup Close Move Page – ‘Wh

Set Page Location Move OK Cancel Click to select the Search

Recently View ed There w ere no re Know n Location The specified pag Brow se Error reading the

You could try relo HTTP Status You must make a Failed to retrieve There w ere no pa Show ing <b>{0}<

Move failed. Ther You cannot move What Are Functio ERP Logistics Op ERPLO

ERP Operations You cannot move Page Ordering Back Reorder Move

Unknow n user or Page Restrictions Editing restricted Cancel Close Save

26769
 • Page restrictions apply
• Added by Rajesh Banka, last edited by Rajesh Banka on Jun 14, 2007
Comment:
view

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 the
Software 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 technical
description 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 available
on 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
4) Business Process Design
5) Business Process Model
6) Business Change & 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.
Edit Add Labels http://w iki.sdn.sa 33351 ERPLO

Labels parameters

Labels
Top of Form
Enter labels to add to this page:

Add Done

Looking for a label? Just start typing.

How to Write Great Functional

Specifications
Bottom of Form
Are you sure you Click to toggle the

While interviewing a candidate with 3+ years of SAP experience for functional consultant
position I asked him a very typical question.
Have you ever worked on functional specifications?
"Yes many" prompt came the reply.
What was the requirement for which you wrote the specs?
"Humm I am not able to recall the exact requirement. I only did some configuration in that. The
functional specs were written by someone else from onsite."
How can you do configuration in functional specs. Can you give me some idea of the
requirement?
Now the candidate was totally on defensive. He answered. "I haven't worked much on functional
specs. I just have an idea about the functional specs."
Needless to say the outcome of the interview.
Sounds interesting?
But its true that based on my experience around 90% of the candidates for SAP functional
consultant position have heard about functional specs. Around 20% have actually worked in
some or the other form on them. However not more than 5% has actually worked independently
and of those half of them lack the correct procedure to write them.
Functional specification comes next only to configuration when it comes to functional
consultants job and without mastering it your SAP experience is incomplete. A poorly written
functional spec creates big communication issue between technical and functional consultant and
the matter is further compounded when they are not sitting at same location. You can only
imagine the mess it will create if the functional spec is not properly written and the technical guy
is sitting in different country and worse still his spoken English is not good (eg Chinese, French,
koreaian etc etc).
Functional specs are written when the standard SAP is not able to meet the client's requirement.
Based on the functional spec the ABAPer will write the technical design doc. and then the
functional guy will test the same in the system and document the results in his test script.
We come across 3 situations which calls for functional specs to be written
1. Enhancements /modifications - If business requires some special procedure.
2. Reports - Client's customized reports.
3. Interface - EDI interface involves ALE/IDOC.

Here are some tips to write great functional specs. The objective should be that the technical guy
should understand it in one go and to reduce any further clarification.
1. Understand the requirement completely. This will depend on your business understanding.
Make sure that the client's requirement cannot be met through standard SAP before working on
it. Please suggest the client if any alternative business process which is supported by SAP and
meets his requirement too.
2. In case of reports you must be competent to decide whether it's a R/3 or BW report. one
example - if the report involves data analytics (like you do in pivot table of excel) it will be a
BW report. However its data collection will be done in R/3.
3. You must mention the business need and business value the report/enhancement will add to
the business. This is for future reference and also to convince the other users.
4. Any legacy system changes to be done once the enhancement/report is run should also be
mentioned. You can mention changes regarding business process or data. This may be an input
for change management team and also for cutover strategy.
5. In case of interface please do mention if it's a display or non display document.
6. Please do not write the structure in place of table and field. Make some effort and find out in
which field the data is stored. ABAPer will appreciate it.
7. Don't just write table and field name but also give the data pulling logic. This is perhaps the
most important part. At times it is really difficult to make the technical guy understand how the
data is getting pulled. Without understanding this he can't proceed further. For example
Target quantity - PACKPO-TRGQTY needs to be transported to Rounding quantity VBAP-
ABLFZ
The data pulling logic for the same will as follows
VBAK-VBLEN doc cat E= VBAP-VBLEN
VBAP-MATNR= PACKPO-MATNR Item cat M
8. Be careful about the data volume while designing the input screen of a customized report. You
must very carefully decide which of these should be mandatory and optional else it will create a
performance issue at the time of load testing.
Please note that every implementation has its own unique format for writing functional specs
however the above mentioned points needs to be covered to make it more communicative and
effective.
For more information on SAP Consulting, implementation, SAP career, SAP interviews please
visit http://www.soulcast.com/ashish1149
Article Source: http://EzineArticles.com/?expert=Ashish_

Functional Specification Format

Authorization Name- Tech Consultant Approval Date
Approval Name- Functional Consultant

1. Solution Information
a) Company-
b) Release-
2.Object Information
a) Object field
b) Functional Specification type- Reports/Interface enhancement
c) Status- Approved/Not Approved
d) Test Scenariao-
e) Priority- High/Low/Medium Or 1 2 3
f) Complexity--
g) Cleint start Date--
h) Clent End Date--
3. Revision History--
Rev No--Rev Date-- User--Description
4.Description or Purpose
a) Description or purpose---Here follows a complete description what Functionality this
specification is going to perform
b) Business proess details-- Here follows the description of business process onvolved
c) Current Functionality--
d) Decide Functionality---
Replay