Tips for Providing Context when Creating Requirements
“It’s attention to detail that makes the different between average and stunning” ~ Francis Atterbury
Have you ever told someone the requirements of a product or service and the result was not what you expected? In my experience, this has been a point of frustration on many projects. The requester felt like they provided the requirement. The receiver felt like they understood. This often comes down to the perspective of both parties. They both can be right, but the requester did not get what they wanted.
As a simple example, let's say you asked someone to take a photo of a cozy little house in the country. If the requester is someone who lives in the western United States, a brown hunting cabin in the woods might come to mind. If the receiver is from Ireland, a white thatched cottage with rolling green hills may come to mind. They both are cozy cottages, but they are completely different things.
As I most often see this disconnect in reporting requirements, let's say the requirement is a report. Here are some ways to help bring the two perspectives together.
This process may take more time during the upfront requirements, but it is worth it in the end. It saves wasted time as well as the frustration of both the requester and the receiver of having to go back and forth, often during the crunch time in a project.
What tips would you add to bring the perspective of the requester and receiver closer together?
Draw a quick picture: A picture is worth a thousand words and can be a great start to setting the foundation for reports, user interfaces, or even processes.
Be inquisitive: Ask open-ended questions to draw out more detail. What would you like in the columns, the rows? What formulas are used in the report? Would you like summarizations? Use the answers to add to the quick picture from above.
Gain context: Ask questions to gain context on the report. What decisions will you be making using this report? How often will it be run? What part of your process does this data come from?
This process may take more time during the upfront requirements, but it is worth it in the end. It saves wasted time as well as the frustration of both the requester and the receiver of having to go back and forth, often during the crunch time in a project.
