When the BA is eliciting requirements that will end up in a use case, it is important they uncover and document the preconditions for tasks. In many cases, the stakeholder will not think about the preconditions when talking about the tasks they perform. This happens because they are so close to the topic, they assume such information is obvious and goes without saying.
If someone is focused solely upon the business needs of a project, they may think that the preconditions section of a use case is one of the least valuable components of the use case. They may consider it nice to have but ultimately its purpose is to add a little bit of flavor to the overall narrative.
If you are a developer or a tester, the preconditions take on an entirely different importance. In many cases, it is the first thing they look at in the use case. The precondition statement describes a system state that must be satisfied before the use case can execute. This means that the code the developer writes will not execute and the tester cannot perform a reliable test, unless the established preconditions are met.
Job shadowing can be a great way to discover missing preconditions for tasks and a solid way to validate use cases. Job shadowing involves participating in the workday of the stakeholder, user or target user group. This participation allows a front row seat to the operational environment when tasks are performed and the challenges that might need to be overcome to ensure the task(s) is completed successfully.
It should also be noted that the precondition information is not always a straight list of checks in a descending order of importance. All the precondition statements are important unless the narrative says otherwise. In some cases, the precondition can be one of more options. In this case, it is important to call out the OR statement for the developers and testers. There is a huge difference in their world between "this AND that" and "this OR that".
Additionally, it may turn out to be a grave mistake to list a precondition that is often but not necessarily needed for the task. This mistake will often go unnoticed until sometime after the deployment of the solution. Then it becomes a change order that may or may not have the same level of diligence in determining the impact of the requested change.
Finally, there is a gap in the precondition component for most use cases. The way they are crafted, it is assumed the use case can be ignored if the preconditions are not met. The potential problem is that this use case might be a precondition of a much larger system. In these circumstances, the BA needs to make sure they communicate what should happen if a precondition is NOT met.
© 2016 Dwayne Wright