Software Requirements Specification Template

We’ve just updated our suggested business requirements document template, though it can be used as a template for any type of requirements specification. You can find it here on our Resources page. One thing we strongly suggest is that you create and update requirements within a requirements management tool and then output as needed to a document such as this. We use Borland Caliber and have found that it is relatively easy to export from Caliber into this format. This is a great way to deliver your requirements to the team, but if you can avoid it, do not use the Word document as your source as you will likely step on each other eventually and it makes traceability very hard!

6 Basic Techniques for Successful Software Requirements Elicitation with Remote International Customers

In this global environment, there is rarely a project we work on that doesn’t have some set of customer users in a remote location, inevitably overseas. While we are typically eliciting requirements in English, we are always faced with ESL customers. So here are a few tips I shared with my team this week as we prepped for such a session with users in China.

1. Communicate their value. Help them understand how important they are to the success of your project. After all, you couldn't possibly understand their business needs as well as they do – with differences in business practices, culture, and preferences.
2. Talk slow. This should be obvious, but it always happens that we talk much too fast, so slow it down. Be very thankful they are willing to talk back to you in English! So whatever you need to do to remind yourself frequently through the discussion to talk slow, do it. Ideas I have include a post-it on the corner of your screen or a co-worker sitting beside you to remind you frequently.
3. Eyes in the room. Have someone in the room, if at all possible, to facilitate the discussion. If you cannot hear or clearly understand a comment (this often happens with large rooms of people and a speaker phone), that person can sit beside the phone and repeat it. Have a communication tool such as Instant Messenger open on a computer that isn’t projecting, so that person can communicate with you about body language – to tell you if you are going too fast or if people in the room look lost.
4. Visual is important. I like to prepare powerpoint slides with small bits of information on each slide pertaining to what we are talking about. So perhaps a screen shot or mock-up with a few features list on a slide. Diagrams and visual models are also extremely helpful.
5. Send materials ahead. As important as visual materials are, they are ten times more useful if you send them ahead. I know I have a better time reading foreign languages than I do hearing them, and this is the case for most. So if you send the materials ahead, they will have a chance to read them and more likely follow along with you during the discussion.
6. Open questions, not closed. Depending on the culture, some people are hesitant to ask questions or tell you something negative. So be sure to ask open ended questions. Instead of “are there any questions?” you would ask “what questions do you have?” – because we know they have some. Then call on people by name to ask what questions they have. Ask their leader what questions he/she has. If they say they are ok with you are presenting for requirements, then you really should ask “What are you concerned about?” or “What have we not captured that you need to have?” or “What are you not ok with” instead of “Is this ok?”.

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.