There’s an old comic strip that illustrates how different players in software development map stakeholder requirements to the ‘solution’. Fortunately, with increased use of agile development and significantly greater input and collaboration with users over the course of development and integration, this gap is narrowing. However, there are still some easy, low effort, high impact ways to improve requirements elicitation that can go a long way towards closing the gap. Here are five:
1. Take a close Look at COTS Product Features/Functions
Many people think it’s wrong to derive requirements from what specific products do. They believe requirements should stem not from what a product does but from what users actually need. In addition, looking closely at products before collecting requirements can feel like putting the cart before the horse. However, vendors have typically spent a lot of money (millions in many cases) to build features and functions based on collective requirements from the market. Why not leverage this investment to accelerate the requirements definition process? It’s OK to jumpstart requirements by doing initial research into various COTS features and functions, as long as you a) do it to facilitate, not replace traditional requirements gathering activities; and b) don’t use it to bypass market analysis and product selection activities after you’ve fully flushed out the requirements.
2. Start with a Strawman Solution for Users to React to
Users are not good at designing software, you are. So help them out by giving them something to react to – a sample solution. You don’t have to create a fully spec’d-out solution obviously, but showing them a simple solution architecture and walking them through it works a lot better than the traditional ‘current state/needs/wants/what else’ approach by itself. It can spark all kinds of ideas and innovation that would not have otherwise been revealed if the only form of stakeholder engagement is in the form of a ‘question/answer’ approach. People simply think and vision better when given starting points to work from. So make sure you give them one.
3. Spend More Time on the Interface
In most cases, the interface is the only part users use. The interface is an often forgotten battleground where perceptions of quality and satisfaction are determined. It doesn’t matter how great the back end is, how reliable or fast the system is, or how great the data structures are if the interface is bad. Ask more questions about how the interface should look/act and spend some time creating simple wireframes (even if they’re just pictures) so users can react to those too. It doesn’t take a lot of time and can significantly increase the ultimate usability of the solution implemented. A picture is worth a thousand words and when it comes to UI, that ‘picture’ can go a long way towards aligning the understanding between developed and user.
4. Spend More Time on Second and Third Level Pain Points
Identifying the basic business requirements and required functions of a system is usually a straightforward effort and typically determined prior to even engaging requirements analysis support. From that point, a lot of requirements analysts devote the majority of time and energy flushing out those pre-defined business requirements and solution functions. However, spending time exploring business pain points in more detail often results in the difference between software that collects data and software that addresses true requirements. For example, knowing that an organization needs a new system to manage industry fee collection and exploring simply what the basic workflow required is, what information needs to be captured, and what reports, controls, etc. are required will result in hopefully a system that fulfills that basic purpose. But what are the real pain points? Perhaps it’s actually getting paid, reconciling payments, or managing workloads. From pain points comebetter requirements; business rules for automated reminders, new report types, or a management interface that summarizes who is working on what by age and volume. The key is explicitly asking about pain points and following up with ‘what else’ until they say ‘that’s it.’
5. Use Simple Surveys to Validate and Prioritize Requirements
Web surveys are cheap, quick, and let you reach a broad audience. However, you are trading depth for breadth (most people won’t complete a survey that takes more than 5-7 minutes). So use surveys to ask users/stakeholders to rank requirements and features to get a better sense of what the solution priorities are. It’s often interesting to see how a larger population prioritizes features differently than a small handful of users. You can always end the survey with open ended optional questions to gather additional insight from those who want to contribute, but far too often requirements surveys are simply a web version of interview questions and that’s not an optimal use of the survey mechanism.
Conclusion
I’ve heard solution architects and developers respond to potential features with, ‘I don’t recall seeing anywhere where users asked for that.’ This, at first glance, seems like a legitimate statement. But why shift all of the burden and risk of good software to the business side? Aren’t we supposed to be the software experts, not them? Some of the most successful and functional software was born from designers and developers, not from asking users what they needed (the iPhone comes to mind..) It’s OUR job to design good, functional, easy to use systems, not users. So leverage user input more effectively by jump-starting requirements analysis with techniques like those above.