In the last blog posts we talked a lot about dissecting requirements. But there was always one silent assumption: That your users and in turn your boss/client more or less all know exactly what they want.
In reality, however, users often do not know exactly what they want. Or maybe they do not know a proper way to figure it out.
So how we change that? How do we stop building software for the trash can and start building exactly what users want?
As always
Before we jump straight to the question of “how do we find out what users want”, we first have to dissect our user-base a little bit.
Note that we are primarily talking about line of business software, from your favourite SaaS start-up to the package & shipping desktop application you might use in your company. (I could not tell you much about e.g. games, and what users really want in games, but for most other types of software, similar rules apply.)
The “natural” requirement
This one is the most straightforward one, as you have (existing or future) users directly asking for it or even demanding it.
Imagine you run an e-commerce shop: Of course you want to have an easy-to-access list of all your purchases, including their prices, customer names etc.
Or you have an accounting software, which needs updates every year as the government regulations and laws change, just like with the EU’s VAT laws in 2015.
Or you are a doctor, running some software for patients, and of course you want to see a patient’s medical history when you open up his file. What did you to/with him last time he visited you? Any images, CAT scans taken?
These examples might seem almost too obvious, but remember: Natural requirements are those that a user really needs in place to get his job/work done.
The “hidden” requirement
Hidden requirements are a bit trickier and you can think of them in terms of improvements to current, already existing workflows. Let me explain, getting back to that doctor’s example, assuming you are a doctor’s assistant:
When a new patient comes in, you might open up his file, take some notes and maybe attach a couple of newly taken pictures to his file. Then you close his file and later on, in the last week of the month, you have to do some invoicing and billing for that patient and all other patients you treated.
Imagine you are already using some patient CRM software and the only thing it can currently do is to give you a list of all patients from last month. Now imagine the following scenario, with 500 patients:
Some of them you immediately invoiced after their visit. Some of them you do in batches at the end of every week of the month. But some you cannot invoice because some details are missing and you postpone them to the end of the month.
The problem is: When you open up that list of all patients from last month, you have no clue anymore who you already invoiced, who still has stuff missing, because there is no filter, no easy way to visually see who has been invoiced etc. It grows worse every month and it literally takes you ages to work off that list.
What you, as the doctor’s assistant want is not a list of all patients who visited you last month, but a list of “still-to-invoice” patients, ideally displayed, almost pushed on to you automatically at the end of the month, considerably cutting down your work time and efforts.
To sum up this example: You have already a workflow in place, which also somewhat works. But it could be improved considerably, always with the goal to cut costs/improve workflows/increase profits. These are “hidden requirements”.
The “hallucination” requirement
Now we come to my favourite type of requirement, the hallucination requirement, often sold to you as “revolutionizing” an industry through “major innovation”.
The main difference to the two previous types is that you do not have direct contact with your customers and you do not want to take small, incremental steps. Instead you sit in your room and assume you know what your customers want and want to offer them the perfect, big bang solution. Yes, the masses would definitely buy XYZ, they have been waiting for it for ages. It is so revolutionary! Let’s build it!
There is of course a chance that you could be right and you hit the right nerve. Kudos to you. But more often than not you are looking at an ego-maniacal product owner, who dreams of being the next Steve Jobs and cashing out on the “start-up” ASAP, instead of building a profitable, long running business.
Note that, in a lot of old-boring business to business contexts this is almost impossible to pull off for too long: Well, yes, your accounting software needs to be able to handle VAT calculations in the EU and end-users do not care if the software is written with AngularJS 2.0. So it will be a lot harder to hallucinate.
Next Step
This chapter was a rough classification of requirement types. The next blog post will cover specific strategies to handle each type of requirement and issues that might pop-up along the way.
Stay tuned!
| Reference: | Software Requirements: How to find out what users want | Part 1 from our JCG partner Marco Behler at the Marco Behler blog. |
