Software requirements review: The workshop way

A few months ago Catalyst was asked by a potential client to go through the project requirements for an ePortfolio system with them in a workshop. There were about 120 requirements with the majority being “must have”, a few “should have” and a couple “could have”. The requirements themselves were mostly of a high level nature and thus providing them with an estimate that was not a ballpark was challenging. The workshop was to help us understand details of the requirements.

In this blog post I describe the idea that we implemented for the workshop, describe the material needed to run it and present its benefits. We ran this type of workshop for the first time and so only have anecdotal evidence of its success. Nevertheless, I hope that it can serve as inspiration to you for re-thinking a similar session you are asked to run and try some of the ideas.

Coming up with an idea for the workshop

Since we were asked to run a workshop, I didn’t want to have a session in which everyone was hunched over their multi-page 8-point font size printouts of the requirements spreadsheet or try finding the line item in the electronic document and waste time searching for items rather than discussing them.

Recently, I had also read the book Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Dave Gray, Sunni Brown, and James Macanufo and was all excited not to run a “regular” meeting but incorporate more visual and engaging elements.

So, I took a fresh look at the requirements. They were categorized according to functional and non-functional areas and labeled “must have”, “should have”, and “could have”. We had also provided information on which functionalities Mahara, the open source software we were proposing for the project, had available out of the box,required only minimal configuration effort, needed some development effort whose scope was pretty well defined, and would potentially need quite a bit of development effort depending on what the client envisaged.

Since the vast majority of the items were non-negotiable requirements, I decided to ignore that categorization. It was also of less importance to keep the topical categorization because we needed to look at the entire solution. Therefore, I focused on the third type of information, namely what the software could already provide and where we needed more information in order to determine whether development work was necessary and if so, how much effort that would be.

Focusing on the software and the elements already available would also help us show the organization how they would already benefit by using Mahara as a basis. Most of the time, an organization’s requirements don’t exactly match any existing software and so a minimum level of customization is required. Identifying the particular items that would need to be customized is important and also having a good understanding of the effort needed in relation to the available budget in order to suggest functionality to start with and then expand on over time.

My expectations for the workshop

In preparation for the workshop, an Australian colleague of mine and I discussed what the organization wanted us to do, what we wanted to get out of the session, what information we had available and how much time we would have realistically. This meeting helped me to formulate the first ideas for the session and then ponder them over a weekend without the interruption of emails and other work. The workshop would need to allow for the following:

Engage all participants and not have them get stuck behind computer screens or lost in spreadsheets.
Allow participants to get up and talk to each other right at the start.
Encourage participants to draw ideas and work flows on a whiteboard spontaneously to support their ideas.
Have the requirements that we are discussing present and accessible at all times.
Make very clear what we already know and where we need more information.
Make good use of time: Spend time only on the items for which we don’t have enough information rather than going through every single item. We probably had a maximum of 5 hours and most likely no possibility of extending the session due to the schedules of all the participants (there were nine from the organization and three from ours).

I came up with a card-sorting idea that would take all these expectations into consideration and hopefully deliver.

The workshop objective

This seemed simple enough: Remind participants of all requirements, quickly deal with only those that need clarification and then move to discussing the requirements that need more information in order to understand them better.

The workshop preparation

The preparation for the workshop consisted of a lot of copying and pasting, sorting of cards and making hand-written notes so as not to forget elements during the workshop.

Material needed

Project requirements in electronic format
Template file that contains the cards as well as the headings
White 160g/m² paper
Printer
Cutting board
Post-it notes in one color that does not correspond to a category color
Highlighter in category colors (or approximations of them)
Sharpie and pen
Two differently colored voting dots (optional)

Set up the main categories

The four categories in which all requirements could be sorted are:

Know / configure: Out of the box functionality, configuration, non-application requirements;
Double-check: Some changes may be needed depending on the interpretation of the requirements;
Clarify: Know what needs to be changed; no major analysis;
Analyse more: Need for more information to understand the requirement.

Non-application requirements such as setting up a hosting contract, offering user support fall under the “Know/configure” category as they are well-understood and part of the contract negotiation rather than software development.

These four categories are then laid out according to their increasing complexity and are allocated a different color each. Initially, I thought of using differently colored paper, but I decided against it because none of the colors that were available went well together. Using white paper and printing color accents on them gives a much more professional look in my opinion. You can even use your brand colors if they lend themselves to it.

Create the requirement cards

This is the part that takes the longest and is the most important. I transferred each requirement onto an A6 card and reviewed the category into which it fell. I also transferred any additional notes that we had already provided the client. Remember, I wanted to avoid that we needed to look up information in a spreadsheet and our proposal document. Therefore, all the information had to be readily available on each card. You can download the LibreOffice Impress template. I set up each card on an A4 slide and then printed 4 slides on 1 piece of paper to get my desired card size. Only the category headings were printed as A4. All cards come out very nicely on 160g/m² paper because they are easy to grasp and don’t feel flimsy.

A4 paper with 4 cards on them

Here you can see the individual elements that went on a card. Due to confidentiality, I cannot show any of the original cards.

A sample requirements card

Provide the number of the requirement so it can be found easily in any document if needed, give it a short title and colorize the background according to the category into which this requirement falls.
Write the word “could” or “should” in this circle if this requirement is optional or use any other word that your client uses to identify additional functionalities that would be nice to have. You may need to shorten a phrase to one word.
Paste the full requirement in this box. If it is very long, adjust the font size. Everything needs to fit onto the front of the card.
If you provided a response to the requirement to the client in the proposal document, paste it in here. This is done in a slightly smaller font to set it apart from the actual requirement’s text.
If this item relates closely to another or is a duplicate, note this down here by mentioning the requirement’s number. This will help you group the requirements later more easily, though you don’t have to think about grouping yet. That is done later.

Once I had transferred all requirements and additional information onto the cards and verified that they all had the correct category associated (represented by the colored bar), I printed and cut them giving me a nice little stack of cards to process further. I jotted down my questions and comments on the back of cards for which I did not want to forget a question or additional comment during the workshop.

Group the cards

I now had all my cards and could start on grouping them into themes. These were partly themes taken from the requirements document or very loose themes only to help review the cards more quickly during the workshop. For example, I grouped all green cards relating to graphic design and all that dealt with support questions. I laid out all cards, took a Sharpie and my little post-it notes and went to task. I did not print out any little cards for this task because I wanted to be able to stick the notes to the cards easily and also make adjustments on the fly if needed.

Not all cards ended up in groups. I did not force the grouping but only used it where it was beneficial. The following shows an approximation of what the cards looked like when we had them on the table at the beginning of the workshop.

The cards all categorized on the table

You can see that there are a few green and yellow cards in the “Analyse more” red group of cards. I decided to put them there so that they’d be together with the other requirements that were very close so they could all be discussed together.

The workshop itself

On the day of the workshop, my two colleagues and I arrived early so we could set up the meeting room for the card activity. It does take a bit of time to lay them all out. We brought flip chart paper, flip chart and whiteboard markers, blue tag and voting dots along. Due to the room’s layout and size, we ended up not using the flip chart paper as we only had a narrow walk way between the table and the whiteboard.

The workshop started with the usual introductions of the participants and the aim of the session. After we had outlined the idea for the workshop to all participants, they were game for it and we started right away. As we were informed of the time constraints of some of the participants, we made a couple of adjustments to our plan and left out the voting of requirements which I’ll explain as an option later.

We asked all participants to stand up and take a look at the requirements and their categorization. This was to familiarize them with the requirements again and put cards into a different category if we happened to have them categorized incorrectly. This wasn’t the case though and we could move on to the next phase after about 10-15 minutes. This phase was not intended to re-read every single requirement, but to just get an overview and take in the requirements that were grouped differently now.

We confirmed that we didn’t need to discuss the cards in green in the category “Know/configure”, and we could put them aside. During a short break, I put them all on a pile to have more space available on the table. This also helped participants see how many requirements were already fulfilled in the size of the stack.

Size comparison of the requirements

We went quickly on to the cards in the category “Double-check” and could deal with them within a few minutes as we only needed to double-check with the workshop participants that we understood the requirements correctly. Where no additional work was needed, I took a highlighter pen and marked the card green. I also noted down the result of the discussion on the card itself. We did the same with the cards in the category “Clarify”.

This now left the rest of the workshop to focus on the cards in “Analyse more”. Initially, I had wanted the participants to rank the cards so that we could discuss them according to their priorities. Everyone would have received five voting dots that they could have distributed onto the cards. The cards with the most votes would have been discussed first. For the end of the workshop I had envisaged participants receiving a second set of voting dots in a different color and voting on the cards again now knowing more about the functionality and maybe revising their priority.

However, since I had grouped the cards already, we had reduced the number of topics. Furthermore, one of the participants had to leave early and so we discussed the topics that were of most interest to him first.

We reviewed each group of cards and discussed their functionalities, what the participants expected of them, why they were important, what work flows they envisaged and where it fit into their program. This was not a detailed review of the functionalities, but did go deeper than the line items in the requirements document and gave us good insight into the reasons for wanting the functionality and what the workshop participants tried to solve. The discussion also gave the participants the opportunity to discuss their ideas further with their colleagues under some different guiding questions and looking at their initial ideas in a new light.

As I was facilitating the workshop, one of my colleagues took notes. This is important to consolidate the information from the cards with the notes later on.

We finished reviewing all requirements satisfactorily in just about three hours and everybody left on a high note knowing that their opinions had been heard, discussed and that we had focused on the important ideas that needed discussing.

A couple of participants remarked that they enjoyed this workshop and that going through requirements had never been as much fun before. One of them also wanted to trial this idea in the future.

Take note

There are a few things that you should be aware of to avoid last-minute panic.

Venue: If you have the chance, check with the meeting organizer that you have a room available with a big enough table, whiteboard, projection screen, Internet access and also enough room for the participants to walk around. Our room was fairly small with a table that was too large for the room making it difficult for people to move. There was a big TV available as projection screen, but it took a bit to figure out how to log in.
Review the cards: Have your cards ready at least a day in advance and go over them with a colleague who’s attending the meeting as well to check accuracy.
Last-minute changes: If you do need to make changes to your cards, know where you can print them if you can’t do so in your office. Our workshop didn’t take place near one of our offices, and printing changed cards proved to be more difficult.
Bring all your supplies: This is a no-brainer for most people, but should still be considered especially if you do not facilitate workshops often. Bring all the supplies that you need so you know you have everything and don’t depend on the venue.

Benefits

The benefits of the workshop were clear to me during the session and also afterwards:

All participants were engaged the entire time.
Nobody got lost in requirements documents, but had all necessary information in front of them on the table.
Participants saw visually how many of their requirements were already fulfilled and how few only needed to be discussed.
We stayed on track during our discussions as we knew exactly what we had already accomplished and what we still had ahead of us.
We finished early because we didn’t spend precious time discussing items that didn’t need attention.

If you think this idea might work for a workshop that you are facilitating, please give it a try and let me know how things go and what changes you made. I’d be interested to learn if it works for others as well.

—

This blog post is a slightly shortened version from the original one.

Products