Although requirements documentation is important in a lot of areas, it is probably the most important as a communications facilitator. By its nature, the creation of a software product is essentially a communication problem. This is, in part, due to the fact that you're creating something fresh out of nothing more than a good idea. Another contributing factor is the diversity of individuals that will create the software product and the diversity of the experiences they have to bring to the table. In many cases the conflict between these talented individuals creates a atmosphere where someone must win and someone must lose. This is more noticeable for teams that have just been formed and less noticeable for teams that have worked on projects together in the past. In almost all cases if one of the divisions of a software product completely dominates the other, the software product loses.
In the most basic set up, you will have a technical team and a business team on the project. It is common that the business team will try to exert what they consider are the technical elements on a project. This, of course, will start a natural conflict because the technical teams know more about technology than the business teams. The reverse is quite often true as well. The technical team may not see the sense of a business need and look to eliminate it from the technology implementation. In many cases, having teams work together on requirements documentation lowers these levels of conflict. If you have a requirements methodology that helps the business units focus mostly on the business communications and the technical folks communicating mostly on the technical implementation, you may have the beginnings of a healthy requirements phase. Here is one method that I have used with successfully in the past, that helps facilitate that type of arrangement.
Have your business units start the documentation ball rolling, a great place to start is defining user personas and scenarios. You may have to monitor business team members to ensure that they are not implementing technical recommendations within these narratives. However you do have to afford them a degree of flexibility, because they are actually trying to visualize a software product.
After you have these personas and scenarios defined, even if just at a high level, then a great addition to that is the user story. Although I think it is proper to have the business unit create the majority of the user stories, the game incredible value once the technical teams get to work with them as well. Much of this value comes in the fact that the technical teams do not know that much about the business, so they bring up questions and help fill in gaps that were created based upon the intimate knowledge the business unit may already have about a particular scenario.
When the technical teams bring at these questions, you can see the business units begin to scratch their head and look at the issue in a new light. This is one of the values that you can have in a structured walk-through. I like the structured walk-through better then email exchanges in regards to clarify and user stories. Using email to clarifying user stories can be a timesaver however many times they just simply get the attention they deserve when done this way.
It would be easy, although inaccurate, to say that you will have all your user stories validated in one structured walkthrough session. However the reality is that you will probably end up creating new personas, scenarios and even business rules during your first few passes. Although everyone on the team may want to groan when they come across something that simply isn’t good enough in one persons eyes, this is a good thing. It is better to get it correct now than have to rework the tasks associated with this “not quite right” requirement.
Additionally, the overall process (although I admit can be tedious at times) facilitates a greater degree of communication between diverse project individuals. If all goes well, this entire process will become a bonding agent between the team members. You will find that you have longer enduring shared knowledge between the project team members and all the stakeholders that they may influence.
© 2018 Dwayne Wright