Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Business Proces...  5 “Joys” of using Excel as a Software Requirements Management Tool
Previous Previous
 
Next Next
New Post 5/26/2010 2:45 PM
User is offline Seilevel
13 posts
10th Level Poster


5 “Joys” of using Excel as a Software Requirements Management Tool 

 5 “Joys” of using Excel as a Software Requirements Management Tool

By Betsy Stockdale

Have you ever used Excel as a requirements management tool?

I am currently working on a large project, a project where the client has licensed a software application and is customizing the application to fit their needs.  The application has numerous modules, and there are several business analysts working on the project, both on the client side and on the vendor side.  Early in the project, the program manager decided to use Microsoft Excel as the tool of choice for gathering and managing the requirements, each module would have their own set of requirements.  It sounded like a good choice to the program manager, since everyone has Excel on their machine and it would be easy to share files amongst all interested parties.

I’m sure that sounded good at the time, but it has certainly been a pain for me.  As one of the business analysts working on this project, I’m getting firsthand experience on the “joys” of using Excel for this purpose, and the extra work that I have to do because of this decision.  Here are top 5 “joys” that I’m experiencing:

  1. Many versions of the same document.  Intentions were good…a SharePoint site was set up where the latest and most current version of the requirements document would be stored.  The business analysts for the client have been very diligent about versioning and updating the SharePoint on a regular and consistent basis.  We even worked out a naming convention for version numbers.  Unfortunately, what we could not control was what the vendor did.  They took copies of our documents, but did not continually get new versions, and then made changes of their own.  Now there are at least two versions of each requirements document out there, and the contents are different.  Which leads to the next pain….
  2. Reconciling the various versions of the requirements documents.  Since we now have multiple versions, they must be reconciled into one master version.  A painfully laborious process when each requirement document has several hundred line items.  Except that the vendor keeps making changes….ugh!  But that also leads to the next pain…
  3. Tracking changes made to the requirements.  Excel offers no ability to track when a requirement changed and who changed it, unless you use tracking.  And since these are working documents, tracking was not used.  We now have numerous requirements that have been identified as part of the reconciliation process as having changed, but no one knows who made the change, when or why.  Attempts were made to keep a change log, but that is a manual process based upon the hope that the person making the change will first note that they made a change, and second, document enough information to make the change log useful and meaningful.
  4. Traceability of requirements is now a manual process.  And given the level of traceability that the testing team has asked for (down to the data element level…but that is another story and blog post!), every change requires another laborious process to ensure that the traceability is also kept up to date.  Many of the business analysts have given up until the decision is made to freeze all requirements (yes, we are using a waterfall development process…again, another topic for a blog…).
  5. Finally, there is visibility.  No one knows who has the most recent and up to date version of the requirements.  Despite all the best efforts.  Ugh.

I know that Excel is a default tool of choice for many organizations, simply because of its ease of use and the relatively low cost (who doesn’t have Excel on their computer??)   And for a small project, Excel may work just fine.  But the larger the project, the more people involved, the more that Excel does not work at all.  How I wish we were using a requirements management tool….

What tools are you using now? How are they working out for you?

To check out another blog about requirements tools, you can check us out here.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  5 “Joys” of using Excel as a Software Requirements Management Tool

Community Blog - Latest Posts

SarikaA
SarikaA
Pega systems(Software Company) is the leading provider of business process management (BPM) and customer relationship management (CRM) software solutions. Pega systems motto is “Build For Change” and their goal is to “eliminate software coding” and “automate manual work”. Pega systems has bee...
0 Responses
Surbhi Mahnot
Surbhi Mahnot
Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is. Just as a system is composed of various functionalities, requirements too are identified in various forms. This ...
0 Responses
Sanjay Yadav
Sanjay Yadav
 Challenges in Implementation:     I’m a strong believer of putting finishing touch to any initiative. Project Initiation is always tough and complex and need lots of research but if BA is unable to give the finishing touch then he is not done yet. So, I thought to put few of my views, challenges and observations during...
1 Responses




Latest Articles

An Overview of the Underlying Competency of Behavioral Characteristics
Jun 19, 2017
0 Comments
While BABOK and other sources include Behavioral Characteristics as an essential underlying competency for business analysts, many analysts may have o...
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC