I have never been much of a writer. To be honest, one initial attraction to software engineering was my belief that the profession did not write much. I always thought that the bulk of the writing came from commenting their code and presenting their work. My current internship at CACI, a company that provides services to many branches of the US federal government, has shown me that’s not the case.

CACI hired me a little over two months ago to migrate a legacy application to the cloud, while also adding to its current functionality. I was very excited. I knew I would be working with technologies/tools I don’t use often such as ASP.NET MVC, C#, AWS, and Visual Studio. I couldn’t wait to get the experience. I’d grown accustomed to entering a new internship with the project specs and requirements already laid out for me. Because of this, I wasn’t expecting to write a software requirements document (SRD) as my first assigned task. An SRD is a written statement of what the software will do. It does not state how the software will do it.

To write a strong SRD for the upgraded application, I first needed to understand the legacy application. Why was it made? How was it made? What functionality does it contain? Why is the migration to the cloud necessary?

"If you don’t know where you’ve come from, you don’t know where you’re going"
— Maya Angelou

Understanding the legacy application was long but necessary. The process consisted of the following:

1. Playing With The Legacy Application
   By interacting with the legacy application, I was able to investigate its functionality. My mentor described the application's purpose and goals, but playing with the application gave me a deep understanding.
2. Exploring The Codebase
   By investigating the codebase, I explicitly viewed/learned the ins and outs of the application. This included error checking and logging, automated responses, and so much more, none of which I would fully be able to grasp through interacting with the application. The legacy application was written in VBA, the programming language of Excel, which I had never used before. The syntax was familiar to me so it didn’t take much time to understand the purpose of each line of code.
3. Documenting The Legacy Application’s Functionality
   By recording all that I learned from interacting with the application and exploring its codebase, I created a well-formatted document of its functionality.
4. Verifying The Legacy Application's Functionality With The End-Users
   By meeting with the end-users, I was able to either confirm my functionality documentation was correct or gain insight into where my documentation differed from the application.
5. Lather, Rinse, Repeat
   I repeated steps 1 - 4 until the end-users agreed the legacy application's functionality had been correctly and thoroughly documented.

After gaining the end-users' approval on the legacy application's functionality, I moved on to considering other functionality the cloud-based application needed. I organized meetings with the end-users to discuss their current annoyances and hopeful additions to the application. I discovered and defined more necessary functionality for the cloud-based application based on the meetings. I was ready to tackle the problem I was hired for.

What else was there to do?
A lot.

Turns out creating an acceptable functionality requirements document is not the same as completing an SRD. My mentor introduced me to a book on how to write SRDs. The guidelines described in the book for creating an SRD became my new guide.

The book clarified what an SRD was and described its importance. It detailed dividing an SRD into three components:

1. Application Overview
2. Functionality Requirements
3. Appendices

The application overview section serves to present the "big picture" of the application. Documented here are the application's objectives, its place in the company's business process, and its relationships to other systems. The functionality requirements section details what the application will do. The appendices section holds any information that does not fall within the other categories. I wrote the functionality requirements already, so all that was left was the application overview.

The application overview for the cloud-based application's SRD contained five subsections:

1. Objectives
   This section details the objectives of the project. After working through the functional requirements, I thought I had a strong grasp of the project's objectives, but I was wrong. I only viewed the objectives of the project from my teams' point of view but never considered it from the customer's point of view. Honestly, I didn't even know who the customer was. I had heard of them in passing but never asked further questions. I initially believed my knowledge of the customer would have a minuscule effect, if any at all, on my work quality. I was completely wrong. I took some time to find out more about our customer through my team members. I learned how the legacy application affected their work. This allowed me to gain a richer understanding of the necessity for the upgrade.
2. Business Process
   This section details the business process and the application's usage in this context. A business process is a set of activities and tasks that when completed accomplish a goal. The business process relates to the customer. This section gave me the hardest time because it required an understanding of the bigger picture.
3. User Roles and Responsibilities
   This section details the users and the application's role within their job. I realized I described this within the functional requirements. I went back to the functional requirements and moved text about user roles and responsibilities to this section.
4. Production Rollout Consideration
   This section details the strategy for populating the system data for rollout. I described two methods of populating the cloud-based application with all the data from the legacy application for production rollout.
5. Terminology
   This section details the business terms used throughout the requirements document. My unfamiliarity with government terms made this section a challenge. Throughout the various meetings and interviews I conducted for the functional requirements, I gained some familiarity with the common terms and abbreviations. It still was not enough to confidently define each business term and abbreviation. I searched for definitions and abbreviations through multiple government documents.

I did not create an appendices section because I captured all the necessary information in the application overview and functionality requirements sections. I completed the guidelines set by the book but was not done with the SRD. I lacked functional requirement priorities. When reviewing other requirements documents by CACI engineers, I realized they all contained priority rankings for the functional requirements. This created a consensus between the developers and customers about a requirement’s importance. I prioritized the documented functional requirements and then proofread and refined the SRD. After I was comfortable, I organized a meeting to discuss the SRD. The meeting revealed more necessary functionalities that would serve to improve the application's flexibility. Other than that, the document satisfied the end-users so I knew I didn't have much left. After the meeting, I documented the new functionality, proofread the entire SRD, and sent it out for verification. I got the green light!

The journey of creating an SRD was long but an experience I wouldn't trade for anything. I’m extremely grateful for the opportunity to do something new. I learned so much throughout the process. Now it's time to work on the project. I'll let you guys know how that goes by the end!