In software development projects, business rules are either a constraint (legal, regulatory or organization policy) or a procedure traceable to some other operation. Remember, software systems are much like an environmental ecosystem. Any change can have affects on upstream or downstream operations in ways that are best discovered before the system goes live.
A professional business analyst can and will perform classic elicitation methods to discover business rules and to validate them. However, business rules can be in the realm of tribal knowledge. Meaning that this critical information is often undocumented by the workgroup but used so often that they assume everyone else knows about it. Interview and workshop methods may miss critical business rules and the business analyst might not have enough time to employ observation techniques.
Even if the BA is employing observation techniques for both requirement and business rule discovery, using use case design is an excellent method to facilitate the process. Use cases are a great way to find information dust bunnies. Sorry, I seem to be really into analogies in this piece. Dust bunnies is a term for the small clumps of dust & hair found under furniture and in seldom visited corners of a room.
Just like how actual dust bunnies are harmful to electronics, these information dust bunnies can cause real harm if they are not taken care of before software deployment. Use cases are like small virtual deployments, it uses imagination to foresee how a new system will impact a process, actors and associated subsystems.
© 2016 Dwayne Wright