Get in touch today: 0800 133 7948 or Email us
Talk to an expert: hello@atlascode.com

Techniques for gathering software requirements

Posted on: December 6th, 2011 by Simon Swords

Gathering software requirements is a tricky yet essential part of any software development process. In a nutshell the process involves speaking with the end users and others with a vested interested in the application, tying them to a chair, shining a light in their eyes and shouting “WHAT DO YOU WANT?!” over and over again.  Sooner or later they relinquish the information you require in order to create a functional specification, which in itself forms the basis of your agreement with the customer.  From the functional specification you ascertain the number of hours required to build the solution, quote the customer a cost, and off you trot to build your application.

Sounds simple doesn’t it?  And for the most part it really is, so long as you get your approach to gathering software requirements right from the outset.  For example, attempting to gather requirements for a £1m project to create a CRM for a multinational company probably shouldn’t be undertaken using Skype, a notepad and a couple of calls to three of the most shouty end users.

So today we’re going to talk about the options available for gathering software requirements, when you might decide to use one (or more of them) and any advantages/disadvantages you should be aware of.

Current system documentation

It’s entirely possible that the stakeholder’s current application has been beautifully documented that lovingly describes in detail how the application works.  This may include architecture diagrams, user guides, and if you’re really lucky a functional specification.

These documents can provide an invaluable, impartial view of the current system that you can quickly and easily copy and paste in to a new specification if you see fit. However, all that glitters is definitely not gold and you should sanity check any functionality you decide to include in your specification to make sure that the current software actually does what the manuals say it should.

Workshops

Workshops are great fun.  They involve asking the primary stakeholders in to a boardroom scenario where you’ll arm them with flipcharts and magic markers in an attempt to extract the most information out of the stakeholders in the shortest timescale possible.

The upside of workshops is that with a lot of pre-planning before the workshop and  6 – 10 knowledgeable people (the sweet spot, any more than 10 people is chaotic) it’s possible to create detailed and immediately useful specifications in a matter of hours or days.  The key to a successful workshop is a realistic plan for each and every hour dedicated to the workshop.  Be sure to build in a buffer so that in the event of an overrun, which will inevitably happen, you don’t run out of time.  You’ll want to have at least one techie there, ideally your best problem solver who can very quickly take a problem and present a handful of possible technical solutions for the stakeholders to choose from.

The downside to the workshop approach is that it is very time consuming and should you make the mistake of inviting even one bad cookie to the event you could find yourself chasing your tail or worse still refereeing two or more arguing stake holders. Definitely not what you want.

Interviews/Meetings

This is a more traditional approach to gathering requirements.  In groups or one-to-one with individual stakeholders an interview gives the developer or business analyst the opportunity to understand requirements using a free form approach.  They then go away and use their interview notes in order to flesh out a functional specification.

This approach is similar to workshops in that it does require planning. In an ideal world you would use a template for every single interview to ensure that the same questions are asked consistently. Furthermore it’s useful to have a schedule for the interviews, and whatever you do don’t miss out a key member of staff.

Scheduling and managing interviews for numerous individuals and groups is time consuming.  You’ll find that stakeholders when questioned on their own may give a different answer when questioned as part of a group so look out for this gotcha.

Questionnaires

Need to engage with a large number of disparate people but you don’t require detailed input from each of them?  You might benefit from a questionnaire approach to gathering requirements. You’re best off using one of the many free survey applications as opposed to sending out dead tree questionnaires if you can help it.  If you’re clever you can create lots of cool graphs from the feedback you receive which your stakeholders will prefer over reams of text.

Questionnaires are definitely not a shortcut, and should not be treated like one. You’ll need to take a hard line with the people you send questionnaires to and set a deadline for the return of information.  Harsh punishments should be dolled out to anybody who fails to return their questionnaire on time. Turning this on its head, we have actually offered rewards for the best questionnaire response in the past. Oh, and be sure to tell your questionnaire recipients how much you value their input – the last thing you want is for them to feel like an extra in your splendid play.

Prototyping

While it is rather lovely to write thousands of words describing in minute detail exactly how every element of your login screen will work, a picture – or a prototype in this case, really does say a thousand words.  There is nothing as powerful a prototype to bring a stakeholder’s ideas to life and the results really are quite astounding.

A prototype can be as simple as some HTML mock ups that allow a stakeholder to click through their screens. Plenty of applications exist for the purpose of creating HTML mockups. Alternatively, if the stakeholders don’t mind spending some of their budget it’s always a good idea to create a proof of concept that you can iterate to the full solution from. Technically this shouldn’t cost the stakeholders more than building the entire application if you box clever about it.

The only downside that we can think of is the cost associated with the creation of a proof of concept. However the potential lost investment in not having a proof of concept if something is technically challenging or needs to be seen to be believed against the small investment in the proof of concept is a no-brainer most of the time.

So in summary…

You will often find yourself having to use one or more of the above approaches in order to completely nail down a solution for a customer. The approach used really does depend on the stakeholders involved and the size and type of project being undertaken.  There are dozens of applications both SaaS and old school (Microsoft Windows) based that will help you to manage the process of gathering requirements, and these are certainly worth reviewing if you feel this would assist you or you need to collaborate with people who are in remote locations.

However you gather requirements, make sure you get it right and don’t commit to writing a single line of code until all stakeholders agree that the requirements are documented in full.

Good luck!  And if you’re stuck for any reason you can always give us a call.

Simon Swords

Director

Managing Director

Want to stay up to date with the latest software news, advice and technical tips?

Loading
;