Functional Specs For Some Payroll Report
What is the procedure to write functional specs for some report?
My client want me to write one for some payroll report. How should I proceed onto this matter?
A functional spec should theoretically mean that the ABAPer should be able to take the design document you have prepared, go and sit in a dark corner of the office and build the whole report..... this rarely if ever happens, but I think thats the theory.
When you write a functional spec, you are meant to be turning the clients requirements into a design document that a techo can then build from.
Some of the things you may want to think about are:
Report logic - What information is the report trying to get, what logical links are required to link the
data together - like master data and payroll data, and org mgt data, and how should this be linked, an important bit to remember here is the time selection, do you want all the data in the system, or only the data relevant on the day, or over a month etc.
Selection screen - What fields are required as selection options
Authorizations - Should the report check the 'runners' authorizations and tailor the output accordingly
Output - What fields are required to be output, in what order, in what file type, for example this could be a text file, or just out to the screen of the runner.
Error handling - What should the report do when it encounters a problem eg what scenarios would
constitute errors - what should happen etc.
Test mode - does the report require running in test mode prior to a file being produced?
What is the procedure to write functional specs for some report?
My client want me to write one for some payroll report. How should I proceed onto this matter?
A functional spec should theoretically mean that the ABAPer should be able to take the design document you have prepared, go and sit in a dark corner of the office and build the whole report..... this rarely if ever happens, but I think thats the theory.
When you write a functional spec, you are meant to be turning the clients requirements into a design document that a techo can then build from.
Some of the things you may want to think about are:
Report logic - What information is the report trying to get, what logical links are required to link the
data together - like master data and payroll data, and org mgt data, and how should this be linked, an important bit to remember here is the time selection, do you want all the data in the system, or only the data relevant on the day, or over a month etc.
Selection screen - What fields are required as selection options
Authorizations - Should the report check the 'runners' authorizations and tailor the output accordingly
Output - What fields are required to be output, in what order, in what file type, for example this could be a text file, or just out to the screen of the runner.
Error handling - What should the report do when it encounters a problem eg what scenarios would
constitute errors - what should happen etc.
Test mode - does the report require running in test mode prior to a file being produced?
No comments:
Post a Comment