Commenters’ Choice: 4 Tips to Not Destroy Your Project if You Must Use Spreadsheets for Software Requirements

ArgonDigital - enterprise automation experts

Share This Post

Happy SeiHolidays! Over the next two weeks, we will bring back some of the most heavily-commented-upon blog posts on ArgonDigital’s Requirements Defined blog. First up: “4 Tips to Not Destroy Your Project…

Joy Beatty wrote, “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. …

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.’ …”

Read on for what happened next…

More To Explore