Technical Blog Post
Abstract
BiLog: Maps and Best Practices....Report Specifications!
Body
Do you know how to fold one of these…..while cramped in car traveling 72 miles per hour…with a husband exasperated that you also don’t know how to read one…along with a dog panting in your ear and your child questioning ‘Are we there yet?’ We’ve since graduated to the amazing electronic GPS technology where a woman in a lovely voice calmly directs us to where we need to go. Truly loving this technology where no folding is required!
As maps define how we get from here to there, report specifications do the same. Report specifications enable us to translate the idea of a report to an actual physical file that can be executed successfully from Maximo.
Creating report specifications is a key reporting best practice. The reasons why specifications so important include
1. Confirms understanding of report requirements between the report designer, and the user requesting the report.
The first step in creating a report specification is having the user requesting the report sit down with the report design to detail the purpose and requirements of the report. This is a critical step as it translates the report image a user has in his head to an actual, feasible report design on a piece of paper. This process will result in a documented, achievable report design file meeting the user’s needs.
2. Enables you to work thru any design questions before the report development process begins. Whether the designer and the user have questions on grouping of data, calculations or whether or not a line chart displays date fields on the X or Y axis – reaching consensus on the answers to these before giving the design to the developer – will save a significant amount of redesign and redevelopment time.
3. Ensures traceability of design changes. This can be especially important for users who tend to continuously change their mind on their requirements.
4. Details report requirements for Report Developer, who may be located in different physical location, may have a different primary language than you, or how may be working on multiple reports. Detailing the exact requirements of the report design in the specification - from its objects, attributes, graphs and layouts -- which is then transferred to the developer so he can develop the report - is key to minimizing any misconceptions or assumptions.
5. Clarifies report requirements for QA/Test. Once a report has been developed, the report goes to the QA group for testing. The QA group uses the report specification to develop their report test plan. Any unique requirements of the report, including if it is executed in a unique way, or under certain circumstances, should be noted in the specification so the QA group can include in their test plan
Have I convinced you yet how key report specifications can be? In subsequent BiLog entries, I'll delve into the details of the three critical components of the report specification process, shown below which are (1) Understand Report Capabilities (2) Understand User Requirements and (3) Detail Requirements thru the Report Specification.
For additional references on this topic, you can access all the Version 7 report reference materials here, including the Report Design Manual here
For additional references on this topic, you can access all the Version 7 report reference materials here, including the Report Design Manual here
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSLKT6","label":"IBM Maximo Asset Management"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]
UID
ibm11133943