No Requirements? No Problem. 

How We Wrote Requirements and Rebuilt a Legacy Desktop Application as a Web Application


Company Summary  

Services

Web development  

Technologies

.NET core, Angular

Project Locations

San Diego, CA, US | Cairo, Egypt

Size

50-55 employees

Industry

Finance

Our customer specializes in financial management services for individuals and corporations. We first partnered with this customer in 2011 to build their customer-facing website. The successful launch of their website opened the door to work on another custom software development project. For this project, our client asked us to rebuild a legacy desktop application, an internal system used every day by all of the employees at the company, as a web app.

Customer Since

2011

Table of Contents

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.


Challenge 

Need a creative solution to your software problem?

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?

Solution  

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 answer is in the project requirements.


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.    


A CLOSER LOOK

Writing Effective Requirements and Effectively Writing Requirements

Need a creative solution to your software problem?

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.   

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

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.   

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

Have questions about writing clear, technical requirements?

Outcome

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. 

Ready to see what kind of solutions we can create for you?

 Contact us today!  

Copyright © 2020. All rights reserved.