Best technique for gathering customer requirements
What are requirements?
This funny image is shown regularly when talking about projects and the disconnect between the vendor and customer. Take a good look, think about it, and consider how this problem should have been solved.
If you’ve ever heard the expression “a picture is worth a thousand words”, consider all the documentation floating around the IT world without a simple sketch anywhere to be seen.
Business requirements are effectively defined as the what is required, not the how the requirement is implemented. Many stakeholders find this part very frustrating because they are most interested in the how. “Show me how it could work, and I’ll understand what trade-offs I may need to make.” There are several approaches to get an idea to a final implementation:
- You know what you want, and I write down my interpretation of what you want in the form of requirements. The requirements get built, and you clarify what you meant to me once you can see it. The implementation is adjusted until it meets the need or money runs out.
- We work together on writing down all the functions that need to be performed. “As a ___, I want to ____ so that ____”. This is a form of user story, and they have various short formats. These small “stories” are potentially easy to estimate and build. These get implemented in batches (sprint), and you can see the results after the sprint is completed. At this point, you can choose to refine what was already done in the next sprint and/or start work on more “stories”. This continues until the implementation is complete or money runs out.
- You describe what you want, and I sketch/draw what it looks like. We work together on how it works with several-many sketches and draw a flowchart for logic behind it. This gets built.
1 and 2 obviously tremendously improve if a sketch is drawn or design is illustrated. Regardless, a picture is needed. This helps the client and the developer get on the same page as quickly as possible. The other key advantage is that with an illustration, you can get a designer to implement your illustration to come up with a beautiful interface. Days when developers would “design” functionality are over, just as the days when engineers would design 80’s cars. Get a talented designer, and get final attractive designs as early as possible.
Once you know what it looks like, flush out all the details of your business rules and logic. Describing, documenting, and guessing are not nearly as valuable as collaboration. Work together as much as possible to get everyone on the same page. “But my client isn’t available for this!” “But my customer wants to pay me to do this!” Unavailability happens, but if you want someone to build something for you, be prepared to pay for their time guessing what you want. Make yourself available, and save time and money.
Apply this effectively
- A picture are worth a thousand words saving time and money, so draw pictures early – don’t be afraid to use a pencil and paper!
- Great interfaces look great, so get a designer on your team
- Work together on business logic and requirements in the same room