4 Tips to Not Destroy Your Project if you Must Use Spreadsheets for Software Requirements

A year ago, I was working on a project where we created a list of features in Excel to help development understand at a high-level what would be in the new system we were building so that they could provide quick and dirty estimates. Out of these estimates, a solution design for the project was chosen and the team headed down the path of a full blown software development lifecycle on these features. Before too long, we recognized the nightmare that Excel was going to cause us, so we uploaded the features from Excel into Borland’s Caliber requirements management tool. The great thing was we could continue to export to Excel pretty quickly for delivery to our customer, since they didn’t have the tool and they were used to that format.

Now also of note, the team decided to use something a bit like SCRUM for this project, so we just treated the features list as a “backlog” of sorts. As sets of features were prioritized for an upcoming sprint, the business analysis team did its elicitation and documented requirements in the form of models from RML™. Throughout this process, we wrote user stories instead of formal use cases, used other visual models as appropriate, and instead of traditional “shall statements”, we wrote “confirmation statements” to describe the functional requirements and business rules. They were used to describe in detail what the system actually needed to do. Oh and by the way, these were all put in Caliber and exported into Word docs as needed for review and development.

Let’s jump ahead 6 months. Our team actually wasn’t on this project for about 3 months, and when we came back to it, we found what I would label “a requirements mess”. I have analyzed this a million times to understand what happened when we transitioned off for that time period that it went so wrong to land the team in this situation. And while I have ideas, the point of this post really is that it just was a mess.

Unfortunately the team stopped using Caliber completely, so all requirements changes and new additions were done in Excel and Word. As is expected, they had lost chunks of work in overwriting newer versions with older versions by accident. There used to be traceability between features and detailed system requirements, but that was completely lost.

What was most alarming and damaging was that the development team believed that the Excel list (which represents just a list of features with one-line sentence descriptions) was the full set of requirements. They weren’t even looking at the user stories, models, and confirmation statements to develop the system! As one might expect, the system developed didn’t really meet the requirements.

And so we headed down a path of narrowing the gap between what was developed and what was required, as well as completing analysis on areas not yet developed.

Over the next few months it became completely apparent how much people love to use Excel. I mean LOVE. Sure enough, one year later, the Excel file still lives as the source of what the scope is on this project. And while they are now using the detailed requirements documents to develop, the Excel list is still the master of all information. And did I mention, there are now about 60 columns to it? And 3 versions of the document that have different information in different columns? I had the exciting task of trying to merge the 3 back into 1, but while I was doing that, someone was editing one of those versions so now we still have 2 versions. Alas we are trying to get approval to get a few licenses of Caliber in place so we can move this spreadsheet back into a management tool.

But the moral of the story is….well Excel sucks for managing requirements, but if you must absolutely use it:

1. Do more than just use Excel – put your requirements details in other formats as well.

2. Be cautious about what information belongs it and what does not.

3. Be careful what you communicate that it actually represents to the project team.

4. And please use a tool behind that Excel to house your data.

An example of Blueprint in Use on an Agile Project

I attended a talk by folks from BluePrint and Lexis Nexis at BAWorld on Tuesday at BAWorld: Boston called "Requirements Definition for Agile Projects". The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from Kathleen McGoey who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and Blueprint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for Blueprint, but it was given by an actual user....and you could tell she was being honest about it.

Blueprint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes are good to an end, but only if the BA knows what they are doing already. She spoke of junior analysts who are given templates and when you look at their work products you think “Oh no! what are you doing!”. I think we’ve all probably seen that. You can use the templates and processes to train them, but they aren’t enough, but they aren’t enough.

Another neat thing she briefly mentioned was the idea of doing something like pair-programming, but where the pair consists of a BA and a user experience expert – so together they are designing the wireframes. I haven’t tried it, typically our individuals are doing both activities.

Anyway, it was good to hear the “how it works” story from Lexis Nexis. And I haven't used Blueprint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

Caliber RM Tip: Dealing with Those Pesky Locked Requirements

If you've used Caliber in a location where your connection is a bit sketchy, you've probably been frustrated by some of the behavior that occurs when your connection is dropped. One of the most insidious problems with having your connection drop and reconnect is the dreaded "Locked Requirement". If you are in the middle of editing a requirement, Caliber RM locks the requirement from use by any other user. This is normally a good thing, since it prevents other users on the same project from wiping out your changes. However, when your connection drops, Caliber doesn't release the lock. The outcome of this is that upon reconnection, the requirement will still be locked under the original session, meaning that you won't be able to do anything with the locked requirement. Typically when this happens, Caliber displays the following message: "The object requested is currently locked by (Username)." When I first saw this, my first response was, "But I am (Username)! Why don't you unlock it?!" Well, the error message isn't technically giving you enough information to diagnose the problem. What it should say is "The object requested is currently locked by (Username) Session (Session ID)." You'll see why below.

To unlock the requirement, open Caliber Administrator. If you don't have access to Administrator for your project, have someone below perform the following steps in Administrator:

1. Click on the "Monitor" Icon. This is an Icon that looks lilke a little gear in the menu bar. This shows you all the active connections.
   
2. If you're unable to edit a requirement that has been locked, you'll probably notice that there are multiple active connections for your username.
3. Start by killing the oldest session associated with your username first. Look at the "Session ID" column all the way to the right. Right-click on the row which has the lowest-numbered session ID with your username (be sure not to kill your Caliber Administrator Session!)
   
4. Click "Logout". This should kill the session under which the requirement was locked. Go back to Caliber RM and see if you are able to edit the requirement which was locked.
5. If you are still unable to edit the requirement, have everyone who is working in Caliber save their work and Logout. Go back to Administrator and kill all the Caliber RM sessions.

After performing the above steps, everything should be copasetic. You should now have the ability to edit the previously locked requirement.

Caliber Tip: Exporting Traceability Diagrams to a PDF or image file

The traceability diagram feature in Caliber RM is pretty nifty. Rather than viewing traceability relationships in the traceability matrix, it allows you to see those relationships mapped out diagrammatically. One of the problems with the traceability matrix is that it can be printed, but there is no native functionality in Caliber that allows you to save the diagram as an image. This can be problematic if you want to show the diagram to anyone who doesn't use Caliber. Well, not to fear! There are actually two ways to save a view of the traceability diagram so that you can distribute it to stakeholders who do not use Caliber.

The first method does not require any additional software, but will only save an image of the diagram and none of the metadata:

1. Open Caliber RM and create a traceability diagram
2. Adjust the view of the traceability diagram to your liking.
3. Create a screen capture of the active window by clicking Alt + Print Screen.
   
4. Open Microsoft Paint
5. Paste either by clicking Ctrl + V, or through the "Edit" menu

You've now pasted the diagram into paint and can save the diagram as a .jpg , .bmp, or .gif. This works pretty well, but I much prefer the following method--exporting the diagram to a .pdf:

For this method, you need a good Print-to-PDF utility. I really like pdf995, because it also allows you to convert your Microsoft Word 2007 documents to pdfs, which comes in handy in all sorts of situations. Once you've installed your utility, do the following:

1. Open Caliber RM and create a traceability diagram
2. Adjust the view of the traceability diagram
3. Choose, "Print" from the "File" menu in the traceability diagram window.
4. In the Printer drop-down, choose "PDF995" or whatever utility you have installed.
   
5. Do NOT check the "Print to File" box.
   
6. Click "OK".
7. You will be prompted for a location to save the file to as well as what you would like to name the file. Name your file and Click "Save"

That's it! I prefer the .pdf method because, although it is not as easily modified as a .jpg or .gif, it displays a nice header and some metadata information about the diagram.