DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Requirements Through Application Exploration

Requirements Through Application Exploration

When adequate requirements fail to exist, developers often have to explore the application in order to derive requirements.

John Vester user avatar by
John Vester
CORE ·
Oct. 26, 18 · Analysis
Like (2)
Save
Tweet
Share
127.87K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Image title

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."

Image title

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!

application Requirement

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Quickly Build an Audio Editor With UI
  • How To Use Terraform to Provision an AWS EC2 Instance
  • Building a Scalable Search Architecture
  • Microservices Discovery With Eureka

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: