AB2007 - How to write Functional Specification v1.

India SAP CoE, Slide 1

AB2007 - How to write Functional Specification

1 2

PrepareMe TellMe
3

ShowMe
LetMe HelpMe

5
India SAP CoE, Slide 2

AB2007 - How to write Functional Specification

1 2

PrepareMe TellMe
3

ShowMe
LetMe HelpMe

5
India SAP CoE, Slide 3

Purpose
This presentation intends to serve a two-fold purpose.

Provide a guideline for consultants who are new to FS writing Fine tune the skills consultants who already have the expertise by highlighting the technical perspective.

India SAP CoE, Slide 4

What is an FS?
Functional specifications (functional specs), in the end, are the blueprint for how you want a particular project or application to look and work. It details what the finished product will do, how a user will interact with it, and what it will look like.

By creating a blueprint of the product 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.

India SAP CoE, Slide 5

Why write an FS?

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 application and can start building it. 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...and this, in a nut, explains the need to write a Functional Spec.

India SAP CoE, Slide 6

AB2007 - How to write Functional Specification

1 2

PrepareMe TellMe
3

ShowMe
LetMe HelpMe

5
India SAP CoE, Slide 7

Components of an FS
Summary
An overview of the sub-systems (if appropriate). An overview of the major functions. Proposed stages of construction/implementation. A summary of the benefits/advantages of the development. Any critical areas likely to affect the success of the development. Any required changes to work practices. Any critical assumptions made during the Functional Specification Phase. A definition of the scope / objectives. Background of the development GAP Analysis
India SAP CoE, Slide 8

Components of an FS
Functional description
A narrative overview of the basic system concepts on which the specification depends determined during the preparation of the specification (e.g. online/real time, System interfaces, possible future extensions, management information, goals to reduce paperwork, or speed office output etc). A high-level context data flow diagram which depicts the System (as a single bubble) in relation to other automated Systems, Departmental areas or external organizations (e.g.. Banks, Solicitors etc), Hardware/system software to be utilized. A narrative overview of the System/sub-system including its purpose, business rules and event timings.

India SAP CoE, Slide 9

Components of an FS
Functional description A data flow diagram of each function within the System/sub-system. A narrative description of each function. Where appropriate cross references to Input/Output Descriptions should be included. For each function the number of inputs/outputs, processes, files and interfaces required to automate the function must be documented.

India SAP CoE, Slide 10

Components of an FS
DATA ATTRIBUTE DEFINITIONS

For each data attribute a brief narrative description, its size, its type (e.g., numeric, alphanumeric etc). Editing and validation rules should be included where these have been defined (e.g., range checks; right justified left space filled etc). A cross reference of data attributes to entities, and inputs/outputs.

India SAP CoE, Slide 11

Components of an FS
INPUT/OUTPUT DESCRIPTION For each input the layout (e.g.. screen design) and data attributes to be included.

For each output the layout (e.g.. report design, fonts to be used, etc) and data attributes to be included.
Control features (e.g., batching, totals etc). Any requirements for maintaining a separate audit trail for additions, deletions or modifications to data attributes.

India SAP CoE, Slide 12

Components of an FS
INTERFACES TO OTHER SYSTEMS A data flow diagram depicting the System and its interfaces to other automated Systems.

A narrative description of the timing and likely method of interfacing to each System.
Cross references to the appropriate description of the interface in input/output description. A description of any alterations required to existing or proposed Systems to accommodate this interface.
India SAP CoE, Slide 13

Components of an FS
USER PERFORMANCE REQUIREMENTS

A description of the Users Online System Performance Criteria described in terms of simple, medium and complex transactions. A description of the Users Batch System Performance Criteria described in terms of the required timings of updates and outputs (e.g., overnight, two working days etc).

India SAP CoE, Slide 14

Components of an FS
DATA CAPTURE/CONVERSION REQUIREMENTS This describes the proposed strategy for any data capture or data conversion which must take place prior to or as part of the implementation process. For example it must cover topics such as whether the System will start with an empty or partially loaded database, how this will be achieved, how tables/code lists will be loaded, which are mandatory fields and what validation must occur, how data takeon will be achieved etc.

India SAP CoE, Slide 15

Components of an FS
TESTING STRATEGY An overview of the testing strategy to be used to test the Object for both functionality and performance (e.g., whether a levels/passes approach to testing will be used, what functionality will be tested in each level/pass, what performance tests will be conducted and how, whether testing will be conducted prior to construction completing etc). A description of the Object Acceptance Criteria and the threshold for Acceptance.

India SAP CoE, Slide 16

Components of an FS
STANDARDS

Define any System specific standards to be used. For example naming conventions to be used for files and screens; or use of function keys; or standards to be used for screens/report headings etc.
ASSUMPTIONS Document any assumptions made during the preparation of this document which may prove critical to the success of the System. For example legislative changes, work practice changes, technical capabilities of hardware and/or system software etc.
India SAP CoE, Slide 17

Ask yourself?
What is the application supposed to be? Pretty basic but critically important. Make sure you have a strong grasp on what the product is before you start anything; additionally, make sure the team you're working with, and the management team ultimately responsible for the product, also have a strong grasp on what you are all doing. Expect lots of arguing and discussion during this stage!

India SAP CoE, Slide 18

Ask yourself?
What is the application supposed to do? Identify the main objectives of this project based on its mission critical factors. Typically, there are one or two core pieces of functionality that make up the bulk of the final product with a bunch of other smaller items thrown in. Identify those core pieces and make them a priority. Do not allow the smaller items to get in the way, but make sure youve made a note of them. A good way to do this is to simply create a list of all the functions you want the application to perform and then rank them based on priority.

India SAP CoE, Slide 19

Ask yourself?
Who is going to be using this application? Find out who the audience is (i.e., who is going to be using this product). Knowing your audience is important in understanding why and how they are going to be using the final application...which is important in defining the scope of the project. Better yet, create use cases and develop user personas. User personas can be a great tool for allowing you, as the writer, to enter the world of your users and see everything from their perspective.

India SAP CoE, Slide 20

Ask yourself?
Is there a precedent for this application? If what you're developing is similar to other products out there, it can make your learning curve much easier by researching those applications and discovering what works and what doesn't. Make it a point to perform a very thorough competitive analysis. Not only will it help you gain speed faster, but it will also give you an idea of what your competition is like and how to do it better.

India SAP CoE, Slide 21

Technical perspective
General Detailed business logic shall help ( A clear idea of the business requirement helps the developer to understand the requirement clearly. A clear understanding of what is to be done will result in reducing turnaround time.)

India SAP CoE, Slide 22

Technical perspective
General Business logic in SAP Sequence of transactions or streamlining of business process in SAP. All related transactions of the functionality Pictorial view or a flow chart of the requirement.

India SAP CoE, Slide 23

Technical perspective
General

When the Functional Speciation documents are interrelated, instead of providing the reference embed related FS. The impact of the object helps the technical team understand the implications of certain coding practices and the logic used in development

India SAP CoE, Slide 24

Technical perspective
General

Lesser use of functional jargon. The layman s language shall help

Terms like routings, BOMs, inspection lots, transfer orders, transfer postings, dunning, MRPs, ATPs are used frequently and sometimes inevitably. In such cases adequate documentation or links need to be provided so as help understand the same.

India SAP CoE, Slide 25

Technical perspective
General Provide table names if possible. Provide sample data upfront. (Sample data helps to analyze standard transactions and to debug the same as well.)

India SAP CoE, Slide 26

Technical perspective
General

If formulae are specified, then each operand needs to be explained in detail with a) Business context b) The methodology to determine the value of the operand. Eg. Formula :- Q=(n1+n2 / c) Say c = no of G.R inspection lots It would help if meaning of n1, n2 and all other variables is explained and how to determine the value of these from SAP tables.
India SAP CoE, Slide 27

Technical perspective
General

If screen shots are used, then complete path to reach the displayed screen should be shown. Eg SPRO->MM->Purchasing->Vendor evaluation ->Evaluate attributes rather than just showing the evaluate attribute screenshot. Whenever logic is specified, it needs to be specified in points as it would be easier to follow.

India SAP CoE, Slide 28

Technical perspective
General

Examples OR Reference to known existing code is added advantage. Will avoid reinventing.
End-user should be mentioned (whether internal/Customer). How errors should be handled should be clearly mentioned. This point is normally neglected. During the course of Development any Change in Functional Specs. Should be formally documented.
India SAP CoE, Slide 29

Technical perspective
General

Authorization Checks to be done in program should be explicitly mentioned.

A description of the proposed system/sub-system/data level security in terms of access.

Boundary Conditions should be mentioned

e.g. Size of Forms, Number of Screen, fonts, barcode size, alignment, etc

Expandability -> State Likely expansion requirements so that the developer can keep this in mind while designing the Program.

India SAP CoE, Slide 30

Technical perspective
General
Assumptions

made by an FS author even regarding the basic functional understanding of a TS author can be risky!!
Wherever possible provide information (even screenshots) & configuration & customizing steps that were carried out which seem frivolous to the FS author but may be unknown to a developer. This will also help the developer better understand the requirement. Example would be how to create a Production Order, Customizing required for Dunning procedure

Details, Details & more Details

important to remember that details are provided as much as possible can also include white-board discussions

India SAP CoE, Slide 31

Technical perspective
Specific - Forms
Printing program -> How printing is planned to happen should be mentioned.
E.g. Printing will be configured in NACE OR Will be done via. Separate transaction. Layouts : In case printing on Pre-Printed Stationary the format to be given exactly the same. Sample Stationary is always preferable. LOGO should be provided. Statutory requirements to be printed should be clearly mentioned in FS.

India SAP CoE, Slide 32

Technical perspective
Specific
Interfaces : Preferred method should be mentioned. Also relevant BAPIs (if applicable) should be given. Interfaces / Conversion : objects the FS should describe the conversion/ transformation rules where the same are dictated by the business Enhancements: FS should clearly mention the current and the desired behavior. Also the steps to replicate the current behaviour should be given. Preferably Test Case Data should be provided.

India SAP CoE, Slide 33

Technical perspective
Specific

Module Pool: Screen fields for all screens should be mentioned. Reference to standard Table fields should be given. Validations. Screen Flow. Data Flow through the screens. Status Bar options for all screens. User Actions. Error handling

India SAP CoE, Slide 34

AB2007 - How to write Functional Specification

1 2

PrepareMe TellMe
3

ShowMe
LetMe HelpMe

5
India SAP CoE, Slide 35

Show me
Here we provide a few sample functional specs which come close to an ideal FS.

PS: These specs are close to ideal, however it is not mandatory to follow the same pattern. They are only guidelines.

India SAP CoE, Slide 36

AB2007 - How to write Functional Specification

1 2

PrepareMe TellMe
3

ShowMe
LetMe HelpMe

5
India SAP CoE, Slide 37

Let Me
Exercise FS_Assignment is a Business Blueprint document which results in a Functional Specification. For the information given in FS_Assignment create a Functional Specification Document using the template FS_Template.

India SAP CoE, Slide 38

AB2007 - How to write Functional Specification

1 2

PrepareMe TellMe
3

ShowMe
LetMe HelpMe

5
India SAP CoE, Slide 39

Some more food for thought.

What are the objectives of project? What are the limitations? Are these limitations generic or specific to this implementation? What is the cost to overcome these? What is the input to the program?

What is the output of the program?

Are there any restrictions to the input? What happens if an invalid input is given to the program? How is the whole software going to run (command line or GUI description)? What are the different command line or GUI options?

India SAP CoE, Slide 40

Some more food for thought.

What are the additional requirements to run the software (libraries, environment variables, paths, executables, other packages/software's etc.) ? How do you plan to decouple first phase from the final phase ? What are the expected deliverables at the end of each phase? How do you plan to test the data? How are you going to verify that the generated output is correct? How do you plan to package the tool? What auxiliary information will be provided to build and run the tool (Release management)?

India SAP CoE, Slide 41