I read an interesting article that is based on some research involving gathering requirements from children. The article is titled Child’s Play: Using Techniques Developed to Elicit Requirements from Children with Adults, by N. Millard, P. Lynch and K. Tracey at BT Laboratories in the UK (article found on IEEE).
The researchers used newly developed techniques to gather requirements from children and then applied those to sessions with adults. Their techniques are very interesting with regard to how you get people to think of ideas they are not conscious of, which is often the case with requirements for a new system.
Some assumptions the article is based on:
• “Work is not simply a process of data manipulation…it is a social artifact.” The thought is you cannot just automate a person’s tasks, but you must look at the requirements in the context of the “social context” and how that might change in the future.
• Requirements do not necessarily already exist, at least at a conscious level for most people. If you just ask them what they want, they will have a hard time anticipating the needs and thinking in an innovative way.
• Children inherently have a hard time expressing their needs freely, so new techniques are needed. They do have a greater ability to imagine, but it is within an experience they already know. And, they do not stay focused on a single thing for a long period of time, so they need to be interesting and dynamic.
In this research, they did a significant amount of role playing of scenarios. This took the pressure off a requirements analyst to pre-determine questions and pressure off the child to think up creative answers on the spot. Instead they put the children in context for the scenario, and let them act out the stories. They found that visual and graphical props for the role playing were valuable for helping the kids imagine the scenario. Once they acted out the scenario they would follow up with a brainstorm discussion, inspired by the ideas generated during role playing.
The premise for this is that it is not sufficient to ask people their opinions on what they want some technology to do. Instead, you put them in a model that lets them act out the scenario and imagine things they would never have just thought up by listing out requirements.
After working through it with children, they then applied this technique to adults. They presented specific scenarios that described social context, and had small groups of adults envision how a specific scenario might impact their job function. The group had to present their response back to the larger group in a form of role playing and storyboards. Again, they got better results from this, than from just sitting down to brainstorm ideas, because they forced the people to be context.
Now it did provide pretty extreme ideas at times, but that just provided more ideas for discussion about the realistic requirements. You can also control the extremeness by developing focused scenarios for the topic and appropriate social context for the project. The output of these role playing episodes, storyboards and brainstorm discussions should be realistic detailed scenarios that put the requirements in a useful context for design and development.
In the end, I’m intrigued enough by this that I’m going to make some attempt at using it in my role at Seilevel to come up with some new ideas. I’ll report back on how that goes!