If you’re a Business Analyst, it’s likely that you’ve heard a stakeholder saying something along the lines of: “This is just a simple table to display, it’s not a big deal!”, only to find out that this table contains calculation- and logic-based data that is not easily available. This was my reality when I was working on a reporting module for property management software in the real estate industry.
In this article, I’d like to share my experience related to reporting requirement analysis. Hopefully, it can help you tackle similar challenges in a better and more effective way.
The reporting module was a part of a property management system made for a global estate agency and property consultancy. In order to demonstrate the scale of the project, let me outline a few quantitative facts:
- The client’s organisation consists of more than 500 offices across 60 territories with more than 19,000 employees.
- The developed system was expected to support a variety of client’s services, including sales and rental of residential and commercial properties. Each of those business branches had its own dedicated application.
- The project had already been in development for 2 years when I joined it.
- In total, 100 people were engaged in the development process.
- There were 8 Business Analysts in the team.
How Did it All Start?
The system was developed in the Walking Skeleton approach. It’s an implementation pattern which assumes building a full range of business-related structures from the early development stage, whereas functionalities around those structures are added incrementally.
When I joined the team which was facing the challenge of reporting, the system had a full set of implemented data structures, including the dependencies between business entities. In addition, the main application flows were already built. That time seemed like a good moment for defining the reporting system. However, in retrospect, I believe that it should have been done earlier.
Of course, having all the data available makes it easier to ensure that certain existing reports can be reproduced in the new system. However, this is not the only aspect to be considered while analysing the feasibility of reporting the implementations that have a significant effect on the duration and quality of business analysis.
Shaping the Requirement Analysis Report
Since our system was expected to replace 4 existing applications which had their own reporting modules, the shape of reporting had to be carefully analysed in order to satisfy the requirements of a different group of stakeholders.
In the systems that were to be replaced, two report types were distinguished: pre-defined and flexible.
The former type retrieves data based on a pre-defined hard-coded parametrised query. The user wasn’t able to make changes to the query or the layout. The selection of parameter values was the only action allowed in order to specify and obtain the report. For instance, in the case of an enquiry about sold properties, the user could filter by the property location, transaction date and/or price range.
The latter type, called flexible reporting, provided the user with the possibility to customise the report query and the way in which the data was to be presented. There also were options to exclude particular search results from the report. A business user could define their own frequently used reports and save them for further use.
Luckily, there were some common features in the two report types mentioned above:
- Tabular data presentation without charts or diagrams.
- Summaries (sums, averages, etc.) of the data shown in tables.
- Possibility of exporting to Excel, Word and PDF.
- Multi-currency support—the property rent or price could be displayed in different currencies. However, if a user wanted to have properties with the sales price between 1,000,000 and 1,200,000 pounds listed, it was required to list not only properties with the sales price specified in pounds but also those specified in other currencies, which meant that we had to recalculate their price on the fly based on the applicable exchange rate.
- Multiple measurement unit support similar to the above—depending on the country where some units are used more frequently than others, the user should be able to see the data that would match the selected values with a specific unit of measurement.
- Multi-language support—our system was multi-lingual, thus it constituted a requirement for the reports.
- Data security—security rules for the reporting system had to be consistent with other system parts. Analysing those rules can be exceptionally demanding, especially in an international organisation, where different countries use different data visibility levels (e.g. China).
Building Our Reporting System
Once we determined the business requirements, we had to decide on the direction of the reporting module design. We took two approaches into consideration.
The first one was to select an out-of-the-box reporting system that would allow us to pre-define as many reports as necessary. It would allow us to implement not only the existing pre-defined reports but also save the most frequently used flexible reports as the pre-defined ones.
Unfortunately, no reporting system available on the market was able to meet all of our business requirements. We tried to negotiate this issue with the client and convince them to give up on some of the demands as well as to change a few reports or descope them. Nevertheless, the client wasn’t willing to go for a package solution.
The second approach was a bespoke flexible reporting solution embedded in the application. It would allow the user to search for the required data by applying a set of filters. The tool presents the search results on the screen, where the user can configure them in a way required for a particular report, and export them to a file. With such a solution, we had to make sure that the existing must-have flexible reporting features would be in place and that the existing pre-defined reports would be feasible to configure within the search-based solution. However, accommodating all of the pre-defined reports in the solution proved to be too complicated and expensive.
In the end, we had to go for a hybrid solution, which was a combination of the two approaches. In order to satisfy so many different non-combinable requirements, we had to implement two separate reporting modules. One to quickly run standard pre-defined reports, and the other one to enable flexible reporting for more sophisticated and complex enquiries.
At this point, it is worth mentioning that reporting performance was yet another factor of having two report types. Since the flexible reporting was implemented as a search-based approach, the search technology was an important factor. The search engine implemented with the Elastic Search proved to be very efficient. Nevertheless, the amount of work required to index all data required for the reporting system was quite considerable. Speaking of performance, exporting the report to a file could also be challenging. Real-time report generation may not always be possible, depending on the computing power of the infrastructure. We decided to implement report generation as an asynchronous process, providing a notification once the action has been successfully completed. Lack of a proper solution to this issue could lead to a great deal of confusion and frustration.
As you may have noticed, defining requirements and finding a proper solution design for reporting requirement analysis is not as straightforward as we may think. Based on my experience, I can offer this advice:
- Start analysing the reporting requirements in the project as soon as possible, don’t postpone it till the end. Reports complexity may affect the technical solution and project timelines. If there are other, higher priority tasks, notify the client of potential drawbacks.
- If you’re building a reporting system that will be integrated into a complex eco-system, make sure you find all the stakeholders willing to use it, and gather as many report examples as possible.
- Check if all data structures required for reporting are available in the data source, and identify dependencies between data structures.
- Remember to consider non-functional requirements (NFRs) such as performance, browsers, devices, usability and security. Skipping one of those NFRs may result in producing a solution that seems great, but is impossible to use.
- Last but not least, analyse the functional requirements around the report generation and report usage. Both of them may strongly affect the tool selection or the design direction of a bespoke solution. Once the requirements are well-defined, my recommendation is to look for tools that are available on the market. You can even negotiate the requirements with the best candidates. If possible, create a report prototype or implement a proof of concept. Go bespoke if all other options are out of the question due to the requirements, cost or other business or technical limitations.