No Requirements?  No Problem. How we wrote requirements and rebuilt a legacy desktop application as a web application 

Before building the client's web app, we had several challenges to address. To start, we had no requirements to guide us on the project and there was only one software developer involved from the original build that we could talk to. Furthermore, the original system was still evolving, and it didn't have any documentation. Plus, we had to maintain the original app while building requirements for the new web app.
On top of all those challenges, the new web app needed to integrate with two websites (one of those being the website we built in our first project) and the employees needed to migrate to the new web app system ASAP.
Our customer's 20-year-old legacy desktop app went through several iterations, and only one of the original engineers was still working on the project. Since the system was integral to the business and daily productivity of its employees, it was critical for us to work closely with the customer to find the best solution for their needs.
Without requirements and knowledge of the business domain, it would be very time-consuming to have the current developers try to understand the source code, and it would keep them from developing the new system. Without a business analyst (BA) at the start of the project, our engineering team had to find a way to create documentation, figure out the customer's needs, and create the software requirement specification (SRS).
Overall, the most pressing challenge for the team to solve was identifying and prioritizing the correct requirements for the project.

Despite having only one engineer familiar with the system and no formal training on how to write software requirements, our team created their own methodology to uncover the scope.

Once the team found a way to engineer the project requirements, they worked with the customer to take a closer look at the functionality of the old system, and they only migrated the most-used features.

The team prioritized functionality and they determined additional features to be added to the web app. Our team also came up with a creative way to mimic the user interface and user experience to help with the transition from the old desktop app to the new web app.

The team worked tirelessly to identify a foolproof solution to the seemingly impossible task of writing requirements.  With no business analyst at the start of the project, we needed to find a reliable way to write effective, accurate requirements.  Our engineers tried something similar to test-driven development (TDD), but instead of using the requirements to build test cases to fail, they did the test case design first to build the requirements. 
This custom methodology was our way of ensuring that we had some documentation prior to having a business analyst join the team. Since we tested the functionality of the old application and designed the test cases prior to development, our engineering team could ask the stakeholders and business analyst more detailed questions, which enabled them to build better requirements.  
The customer knew the important aspects of the desktop application they needed to see in the web app.  
We figured out how to test them.  
We worked closely with the client to ensure that we were only including the necessary requirements from the desktop system in the web app, and this resulted in a simplified and more effective web application.  

Revamping an app gives companies an opportunity to keep the things they love about their original app while also adding new features on their wishlist.  We had to be mindful that the legacy system was still improving while we began development on the web application.  

As a result of this, we ensured that the new web app’s functionality was on-par with the old system. Our team recognized that the same employees would be using both of the the systems, so we closed the functionality gap between the legacy desktop app and the new web app.  

Our goal was to get employees to switch to the new system ASAP.  To speed up the transition, we moved certain pages from the old system to the new system without changing them, but we knew that we could later add more functionality. This approach enabled us to get the functionality of the new system updated much more quickly and efficiently.  

One way we motivated employees to transition to the new web application system was to make the new application feel similar to the legacy desktop app.  

The original app had hundreds of screens with tabs that integrated with an online system and database. While the new app cuts down on the number of screens, the team was still able to mimic the desktop app’s tabbing by adding them as iFrames, and this eased the transition from the old system to the new system.  

In addition, this gave the web application a desktop-like user interface.  The tabs are inside the application rather than in browser tabs. Employees can open multiple screens and switch seamlessly between them without losing their place.  Plus, this helped the team to roll-out the new system in less time.  

The first major release of this project was launched at the end of 2019, and the estimated completion date for this project is December 2020. To date, we have streamlined the number of screens within the app by an estimated 80% while also cleaning up the app and adding new functionality.  Although the system is not fully implemented yet, we receive regular feedback from users, and it has been great so far. We hope to continue adding to the everyday efficiency and productivity of a truly great partner of ours and you can sign up below to keep updated on this project’s status. 

No Requirements? No Problem. How We Wrote Requirements and Rebuilt a Legacy Desktop Application as a Web Application

Company Summary

Services

Technologies

Project Locations

Industry

Size

Customer Since

Table of Contents

Challenge

We help our clients create impact across many industries. See how on our case studies page!

Solution

You might be asking yourself, how did we rebuild the legacy system and include new functionality, maintain an old system that was still-changing, and ensure the new system had all of the features employees needed to complete their day-to-day work?

The answer is in the project requirements.

A CLOSER LOOK

Writing Effective Requirements and Effectively Writing Requirements

If you’re curious about additional services, check out what we can offer you!

Playing Functionality Catch-Up: Don’t Reinvent the Wheel

Ensuring Consistent UX/UI from Desktop App to Web App UX/UI Continuity

Let's get together. Set up your free technical consultation and find out how we'll bring our experience to successfully execute your next project.

Outcome

Related Content

A Twist on Test-Driven Development to Transform Our Customer’s Legacy Desktop Application into a Modern Web App

We upgraded a legacy desktop app that was running on outdated technologies to a modern digital web app, and you can learn more about how we did it here.

Employee Migration and Adoption to a New Web App

We rebuilt a legacy app as a modern web app by taking several key considerations and best practices into account. You can read more about what we learned here.

Subscribe to our newsletter!

We've been in the software industry for 30+ years so we have a lot to share with you!