Over a million developers have joined DZone.

Software Requirements: How to Find Out What Users Want

DZone's Guide to

Software Requirements: How to Find Out What Users Want

What's most important is knowing what users want, what they really, really want. Check out these strategies for defining software requirements.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

In my last blog post we talked about the different types of software requirements. But how do you generate them, in the first place? What about practical strategies? How do you find out if you are hallucinating or if you really stumbled upon something the masses might want? And how do you find out about those hidden requirements?

Let’s roll!

Humble Inquiry

It might almost sound too simple. One of the best strategies to find out what users want is to actually ask them and then listen carefully. If you have existing customers and run an online company you will surely already get feedback via email, forums or other social media outlets. So all that is left to do is listening.

There is one very interesting point to consider why people fail to ask a (future) customer questions: Because they are scared of not delivering a perfect solution the very first time around. Scared that it puts them in a bad spotlight, because they are supposed to be the all-knowing specialist – but suddenly they have to ask for feedback/information/advice!

Do not make that mistake. Your users appreciate if you ask them for their feedback and if you make their lives better. It is not about you magically knowing everything all the time.

So which type of requirement is the humble inquiry best suited for: Yes, the natural one.

Sitting With The User

What about hidden requirements though? What if the user does not really know what he wants?

Simple: You need a technical outsider to sit with the user for a certain amount of time, observe him, understand the existing workflows and then try to make improvements to that workflow. This needs a certain amount of trust from the person being observed and the willingness to have a “follower” for larger parts of the day and explain things to them.

Additionally you need a technical person who is willing to not only talk “tech,” but also domain and user experience and who is sharp enough to see those improvements in existing workflows and translate them to software requirements.

You will be surprised about how much you can learn observing someone and how many improvements could be made to everyday business workflows.

The Lean Start-Up

But what if there are no existing users, no existing workflows and you are building something from scratch?

Actually you can and should always learn something about your users, because they probably post about their software experiences and pains in forums or on social media. But if you are really talking about brand-new innovation, then the only reasonable way to find out if users want your software is to build it (or rather the smallest viable version of it), put a price on it and then sell it.

Sales are going to be your user feedback. And for this to work out, you need to build small bits and pieces of your software, have short iteration cycles, go live often and NOT try to build the magic, can-do-everything for everyone type of software.

Software developers often are in feature-berserk mode, because that is what they are used to do: Build stuff. The more, the better. But instead of saying yes to every feature and build as many as possible, you should say NO to every feature by default and only commit to those features that have an immediate impact on your users. (This is a huge topic however and I cannot do it justice in one paragraph. If you have any thoughts or questions, shoot me an email).

Next Step

If you liked this post, sign up for our newsletter or follow @MarcoBehler on Twitter. As always, stay tuned for the next article in this series!

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

agile ,lean

Published at DZone with permission of Marco Behler. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}