Blog

How to Gather Better Requirements for Custom Software Development

April 21st, 2010

Application Development, Technology, Usability

I’ve been building software applications for about 15 years and I have come to one inescapable conclusion: the best apps are the ones that I think of myself and build myself!

Sounds quite pompous doesn’t it? I guess what I meant by “best” apps is that the custom apps that worked the best, fulfilled requirements the best and solved the intended problems the best were the ones that I thought of myself and built myself. Why is this?

I think this is because the most difficult part of custom software development is not writing the code or building the architecture or picking the tools – it’s describing what you want. It’s figuring out the requirements. The hardest part is translating the needs and desires of the customer to the developer. When I write software for myself I am both the customer and the developer so there is no translation needed! But when I write software for someone else there is a transfer of knowledge, needs, desires and requirements that is required.

Why is this so difficult and what can we do to make it easier?

Well, I believe that this is difficult because software and business systems can become very complex and as a result there are lots of places where there can be miscommunications and assumptions. There are many other fields and disciplines where a contracted individual creates something for a customer. Construction is one example. A simple example is when you purchase a home from a builder. Usually the builder has a half dozen different models and often times there are actual examples of the models that you can drive to, visit and walk around in. Usually the models have examples of all of the different options that you could purchase. Plus people are generally familiar with homes, they know what to expect and they know what not to expect. So in reality when you purchase a home from a builder there are relatively few choices that you make and the choices that you do make as a customer are things that you are very familiar with and you’ve also had the chance to walk around in a version of the actual house that you will purchase.

In software development this would be similar to purchasing a software product that is already built and then modifying it. It’s a fairly low risk endeavor and you also get the chance to sort of “walk around the house” a bit and try out a version of the actual software you are going to purchase.

But *custom* application development can be quite different. It is much more like building a custom house or even a custom sky scraper. When building a custom home or a custom building there is no model that you can go visit. A builder could point out certain features of other similar buildings that you could see, but often times you are left only with construction blue prints or artist’s renditions of what the final structure will look like. And it can be hard for the customer to really “visualize” what the finished structure is going to look and feel like. While you can look at the blueprint and see that an office is going to be 10′ x 15′ – it’s more difficult to really get a sense for what that room is going to feel like, how the sunlight in the morning will come in the window, what the acoustics will be like, etc.

The same is very true for custom software development. It can be quite difficult for non-technical customers to really be able to “visualize” the finished system and see how it’s going to work. And because they can’t really see the completed system in their mind, it can be very difficult for them to explain to the developer how it is supposed to work.

So what are we to do? Here are some best practices that can be followed when developing complex custom software applications.

- Build “model” homes whenever you can. Create examples of your software that show off major functional features so that customers can “walk through” different screens and get a better feel for how things might work.

- Build quick non-functional prototypes that walk through complex functionality / use cases. There are many tools out there that help you build quick prototypes.

- Build “artist renditions”. Create mock ups of key screens that show as much functionality as possible. Whenever possible pull things from your “model” home to make this exercise even quicker.

- Create annotated visual functional requirements documents. I’ve written a lot of functional requirements documents over the years. I have found that if your requirements document is entirely text that describes every piece of the system, customers will generally just nod their head yes to everything. The truth is that no matter how eloquently you write and how painstakingly you describe every use case, the reader’s eyes will glaze over. Most customers who are purchasing your software are visual in nature. They need to see it to really understand how it is going to work. Sometimes you have to write out the details of a particular feature – but it should always accompany a picture.

- Learn the business needs as best as you can. Remember – we are striving to improve the transfer of knowledge between the customer and the developer. The more the developer knows about the customer’s business – the better they will understand the problems – the better they will be at describing the solution. Often times there is a tendency to want to skimp on this step to save money because it doesn’t seem like we are really producing anything. In my experience, this step can be invaluable and will actually save you money in the long run if you invest a little more time up front.

Custom software development can be quite challenging. However, with a little work you can make the knowledge transfer between customer and developer much more efficient.