Requirements Through Application Exploration

Working on a project for a department within a State agency, I encountered an interesting observation when I took a break to visit the restroom facilities. As one might expect, this was a break that happened every day I was on-site at this project.

The first time I visited the sink to wash my hands, I noticed nothing happened when I motioned my hands under the sensor. After a couple attempts, I moved to an adjacent sink, which did accept my waving hands and water was provided. When I visited the sink the rest of that day, I opted to use the sink that worked, which was no problem.

The next day I was on-site and found myself in the same position, I went to that same sink. However, this time my waving hands did not trigger the water to start flowing. So I selected another of the five sinks, which was also not working. For fun, I tried to use that original sink I had tried the day before. Guess what? It was working this time.

It almost became a game, to try to guess which sink was going to work. As much as my analytical mind tried to establish a pattern of when a given sink was active, I determined it was purely random.

Then I began to wonder how such actions can exist on a project.

The Situation

We've probably all been in a similar situation, where a piece of information is not known and it becomes an added responsibility as a feature developer to solve the mystery. More often than not, the experience is driven from an unexpected bug that was driven from a use case or requirement that was not captured. This is expected, since no single team member will be mistake-free in their efforts on a project.

A recent situation that I encountered was different. It was basically something called "requirements through application exploration" by Billie who was on our team. In this case, we did not have fully documented requirements and acceptance criteria for the application we were replacing. As a result, we had to go on a full discovery to try to figure out all the logic in place through review of the legacy source code. Additionally, we started using the application as different user roles to determine the rules and logic.

The Good

The benefit to taking this approach, is that the feature developers can get started quickly, without having to wait for a Product Owner to fully document and vent out the requirements, acceptance criteria and any alternative flows. On the surface, it seems like a time-saver and a quick way to get started on an initiative on day one.

However, the reality is that this is not an ideal approach.

The Bad

The biggest challenge to taking this approach is the probability for errors in the analysis of the requirements.

First, the assumption is being made that the legacy application's program code truly depicts the current business rules and flow logic for the current state. Often, this is not the case, as the legacy application represents a point-in-time snapshot of the business requirements. Without a Product Owner in place, knowledge of manual workarounds or alterative flows will be missed.

Secondly, as a developer reading the code or trying to figure out what needs to happen by using the existing application, we tend to see what our minds wants us to see. In the spirit of trying to solve the issue promptly, our mind naturally tries to jump to conclusions. This can be in the way a method is named or at a glimpse into the code without diving into the details.

Regardless of the source language it is easy to miss a method call that performs tasks that are not expected. In one case, the client actually had business logic in their model tier — which is typically reserved for one-to-one mappings to the persistence layer. By failing to review this aspect of the code, critical business logic was missed.

Back to That State Agency

I brought up that State agency in my intro for a reason. While on that project, I was asked to document what the code was doing by the Product Owner. The system we were working on was purchased by another State agency and was being updated to match the business rules of their State agency.

The logic was focused on over-payments made by the State agency and processing the rules around getting money back from an outside entity. As I worked through the code (which was buried in a lot of stored procedures in the database), the logic seemed pretty solid. From an outsider's perspective the business rules seemed to make sense to me.

I documented the rules and presented them to the Product Owner and a few members from the business team that handled these activities. As I finished, I expected my captive audience to say, "Yes, that is how we do things."

Instead, they said, "We have no idea why the system is doing this."

It turns out the processing was still reflecting the business logic for the other State agency who sold them the application. What started as a requirements validation effort ended with a series of tickets in our ALM system to update the business rules. At that time, we opted to pull the business logic out of the stored procedures to match our current design patterns.

In this case, reviewing the logic allowed me to understand the business rules...but they were the wrong business rules.

Conclusion

Asking development resources to determine requirements and acceptance criteria through application exploration is a subpar approach.

Like my experience with the bathroom facilities at the State office building, there are a lot of assumptions and guessing that happens — which ultimately leads to invalid information. I could never correctly guess which faucet was going to work for me...but my skills of quickly navigating from one sink to another became quite impressive over the course of the project.

Additionally, looking at the source code to try to drive out requirements is not always a good idea - since legacy code can exist which is not related to the application at all.

While it can seem like a swift way to determine the requirements and acceptance criteria, the risk of not having actual information from a Product Owner will lead to delays from ensuing rework that will come from the testing phase.

Have a really great day!