Webtrieve – Initial Discovery

Welcome to the Webtrieve project series. If you want more details about this series, jump over to this post and get the background.

This post will describe the initial preparation and discovery for the Business Analysis from specification through to Product Manager sign-off.

This project is the re-development of an existing application so a lot of the work has already been done. That is, I have an existing application that is my specification. What I needed to do is break the existing application into pieces of functionality and explain that functionality in a specification document so that the developers can re-create the application. That being said, the new application will not be an exact replica of the original system. The customer wants to incorporate new functionality but the core will be based on the existing application.

Easy, right?

User Story Excel Template. List the functionality that is easy to replicate into a specification document.

The first thing I wanted to do is capture the existing functionality in the current application. To do this, I went through the entire application and detailed each piece of key functionality. I created a User Story Excel template for each screen in the application and then listed the User Stories for that screen.

These User Stories will form the basis for the Features that will be used in the Traceability Matrix later in the project. We will get to that later when we create User Stories for the new application and map them to functionality in the old application. This will be how we make sure we don't miss any functionality in the migration. Also, these User Stories will be the Use Cases that I reference in each specification document. Again, this relates to the Traceability Matrix that will will discuss later. I didn't spend a lot of time on each User Story because they are for reference only. I just need to know what each User Story relates to when I start mapping them across to User Stories in the new application.

This gave me a complete story of the functionality in the current application.

As I was working through the User Story process, I noticed that there was a lot of shared functionality across screens. I thought it would be a waste of time to replicate this across specification documents, so I took all User Stories from all User Story templates and pasted them into one master document and added a column that described the excel template each item came from. Then I sorted the list and "singularised" the User Stories. I didn't need the duplicated stories because I was just detailing the functionality, not the screen reference. I will be able to map the functionality to multiple screens/modules but we will cover this later.

This is my core list of User Stories that I will write the specification documents from. I classify the list into seven categories and these will be the topics of the specification documents.

Another reason why I wanted a number of specification documents is so that I can distribute one document for review while I move on to the next document. By the time the stakeholders have reviewed and returned their feedback on the first document, my next specification document will be ready for review. I heavily used the track changes functionality within Word to keep track of each stakeholder's feedback and I always kept an appendix that detailed the comments for each stakeholder. This was an onerous task, but it proved to be useful later when comparing changes and determining who said what and when. Much, much easier than handling these things via email. I used another tool to help with feedback that I will discuss in the next post about the Forum Discussion Application.

At the end of this process, I had seven specification documents that all stakeholders had read and given their feedback on. These specification documents detailed the functionality in the current application. All stakeholders had given their approval and the Product Manager had given sign-off on all documents. Next, I needed to capture and incorporate the new functionality.

I considered options and decided that the best way to capture this information would via an online application. The stakeholder group is across multiple timezones so I wanted to reduce the delays produced by email and possibly omitting people from threads etc. This application allowed users to enter a functionality request and justify the inclusion. Once added, all stakeholders had the opportunity to give their support or ask questions about the suggestion. This application will be discussed more in the next post.

Til next time ...