Getting to the real problem
Writing requirements is hard. Writing good software without proper requirements is even harder, at least if you want to have a happy customer at the end of the project.
The everlasting paradox in requirements engineering is that you are trying to get an insight in the needs of stakeholders, even though the stakeholders often don't know what they need. When they do know what they need, it's not uncommon for them to get it wrong.
We - software developers - often skip right to the solution and you can't really blame anyone for falling into this trap. Are you supposed to read the stakeholder's mind? In order to find a proper solution you have to take time to understand the real problem and context.
The requirement engineering process might look a bit like a dark art for the uninitiated, but there are some really simple tricks to get to the bottom of the problem in your problem definition phase.
This article was inspired by a guest lecture from Klaas Jan Wierda at Océ. Thanks for giving me some insight in your requirements processes.
Context inquiry
When you're in the business of optimizing or automating workflows (who isn't?) it is of massive importance to actual have a clear view of what these processes actually entail. A process always has a bottleneck but actually identifying the problem might not be apparent to the person performing the process.
In a context inquiry you visit the user's workplace and literally watching them do their work. This includes their time in front of the computer as well as other tasks. There is no fabricated, make-shift process, only the real, raw thing.
Following a single person (for a part of) a day will help you develop a certain empathy for the user. You are the fresh set of eyes that should spot the different problems the user runs into throughout the day.
During the session you collect a wide variety of qualitative data, ranging from interviews, videos of processes or even GPS waypoints. After the sessions you can use this data to analyze the processes, convince other stakeholders or even use it to get the development team up to speed. Clear problems often come with clear solutions.
Problem trees
A problem can be the consequence of different actions and not necessarily single one. Humans have a hard time actually mapping these interdependencies mentally. Keeping an open mind when you think you've found the cause is hard, especially when you don't know the full context.
A problem tree helps you change your perspective on a single problem and will often make you realize that introducing yet another system is not best or only solution. Maybe a company is better off changing one of its policies or hiring extra staff.
Making these kind of trees is often interesting for layered problems, problems that span a longer time or multiple stakeholders. Capturing this in text is hard and these trees often develop throughout the discovery processes.
The five why's
The easiest technique for getting to the real problem is repeatedly asking why a stakeholder wants a certain solution or has a certain problem. You can compare this to traversing a problem tree. A typical transcript of replies for a company that wants an iOS application might look like this:
Every company has one!
Because it allows people to read about our company on their phones.
Because our normal website is hard to use on small screens.
In this case you might end up recommending a mobile/responsive site rather than a native application. You probably won't even need five why's (and I wouldn't recommend literally saying 'why' five times in a row) to get to the real problem.
Another paper tiger?
Some projects don't need extensive requirements or clever techniques to gather requirements. In smaller companies or organizations with clear processes there is not much use to have such an extensive discovery process. Just make sure you really know what the problem is.
Another thing to consider is that changing requirements up front is really cheap. You're better off spending two extra hours talking with your customers than ten hours rebuilding part of the system (unless you're paid by the hour of have a good contract..). Good requirements help a long way in creating better systems and ultimately happier customers.