It’s probably not all that often in our lives that we get to see things from both sides of the requirements. As developers, managers, testers, etc. we don’t author the requirements. We don’t generate the idea. We help the folks on the business side make requirements out of their ideas.
And, we constantly bemoan how horrible it is that business people can’t seem to put requirements on paper to save their lives. They don’t know what they want. They keep changing their minds. They’re too detailed – they give us solutions instead of problems. It seems like they can never do right by us.
In an interesting experiment, I happen to be working with a group of college students who are doing a Senior year project. As part of that project, the college solicited assistance from a range of companies to act as customers and have the students solve a programming project for them.
Without getting into detail of what I proposed, I gave it a bit of thought, and ultimately settled on a simple tool to assist with generating data for testing. It seemed straight-forward enough. As I sat there writing up a short requirements document for the students, I thought to myself how pleased I was to get a chance to do this. The tool was so simple it didn’t need use cases. In my mind, just a context diagram or two, a simple data model to illustrate the goal, and some text around the various types of output it had to generate was all that was needed.
In my head, having been a programmer many years, I knew exactly how I would solve it, but I tried very hard to not impose my idea of a solution on the students. After all, I had very little strong opinion on how most of the solution should work – certainly no opinion on a user interface, how it would connect to the database to create the data (could be ETL, could be ODBC, could be something else), etc.
On the day of the first meeting with the students, I printed out 5 copies of my requirements and off I went to meet with them, as well as their advisers, on campus. Even after explaining the problem several times, the students seemed confused. The advisers seemed confused. In the whole room of people, it seemed like I was the only one who wasn’t confused.
What had gone wrong? Were my requirements that bad? How was it that someone who had so much experience on the development side of the business couldn’t write a requirements document to save my life?
It was a day or two later when I had a serendipitous moment. In working with another totally unrelated team on process work, we were discussing the need for the team to have autonomy to make their own decisions. This is not normally something I’d support since autonomy = not standard. When we finally rolled out a necessarily vague process to enable their “autonomy” the users of the process freaked out. They didn’t know how to use it. They wanted much more detail. The autonomy they desired was only after they had seen a complete answer. Then they could pick it apart and tweak it.
That’s when it struck me. I wrote my requirements giving the students enormous autonomy. As a developer who had been through lots and lots of projects, I too desired autonomy to make design decisions to help solve the problem. So, when I wrote my requirements, I wrote them the way I would like to receive them. With 15+ years of development experience, I don’t need someone to spoon feed me requirements anymore. But these were college students. Having solved very few real world programming problems (perhaps none, for some of them), giving them a problem to solve was vague, hand-wavy, and generally dissatisfying. They freaked out because they didn’t have the experience to derive an answer themselves; they needed it to be more detailed and perhaps even give them a (partial) solution to the problem.
Had I done that, the students could riff on the solution, but not create from nothing. I’m not sure how to incorporate this discovery into a methodology yet. If you encounter experienced developers, they don’t need that kind of detail, but if you encounter less experienced developers, they do. You could err one way or the other, but why write lots of detail to be ignored by developers who don’t need it? Or worse, why generate so much job dissatisfaction by treating them like college students?