One of the great myths of software development is that we can ask our customers to tell us what they want, that they will write these items down for us as requirements, and we can then successfully build software based on those documents.
As Henry Ford noted:
If I had asked people what they wanted, they would have said faster horses.
It’s important to start your development journey by understanding as much as you can about your customers: those you hope will find enough value in your product to be willing to exchange something else of value for the privilege of using it.
Requirements are hard to understand and harder to specify. The wrong solution to this problem is to do a slipshod job of requirements specification, and rush ahead to design and code…. The right solution is to do whatever it takes to learn as many of the requirements as possible now. Do prototyping. Talk with more customers. Work for a month with a customer to get to know his or her job firsthand. Collect data. Do whatever it takes.
Here’s a product development story that James M. Morgan and Jeffrey K. Liker tell in their 2006 book The Toyota Product Development System: Integrating People, Process and Technology that illustrates Davis’ point:
While developing Toyota’s successful 2003 Sienna, the Sienna CE [Chief Engineer] drove his team in Toyota’s previous minivan model more than 50,000 miles across North America through every part of Canada, the United States and Mexico. The CE experienced a visceral lesson in what is important to the North American minivan driver and discovered in every locale new opportunities for improving the current product.
The requirements analyst has to inject something new into the process: his vision of what the product might be. In other words, the requirements are not simply the passive interpretation of an existing piece of work, but contain inventions that will make the work easier, better, more interesting and more pleasant.
Defining one or more user personas is often a good way to help developers form useful pictures of what their users are like, and what interests and preferences their users may have.
Taking all of this wisdom into account, here are what I would consider the key points to keep in mind about requirements.
Software requirements must be grounded in a solid understanding of your customers and the way they see the world.
Requirements may be explicitly stated or implicitly understood.
Requirements analysis is a creative process that discovers or even invents new approaches to stating and addressing your customer’s wants and needs.
Requirements prioritization is essential, to provide focus to both your elicitation and delivery: trying to discover all possible requirements is an endless job, and creating a design that gives equal weight to all requirements is a recipe for disaster.
Requirements are dynamic. Change is inevitable, and the best way to cope with this reality is to try to discern the difference between requirements that are likely to be fundamental and unchanging vs. those that are likely to be subject to the latest whims of management and users.
Requirements validation requires us to show our customers what we propose to give them.
A certain degree of risk is inherent in the process, and your best approach is not to try to avoid risk altogether, but to try to keep the degree of risk within acceptable levels, while also being mindful of cost and schedule.