Software Development

Use Case Preconditions And How They Are Leveraged

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. 

Yeah, it is a wedding reception picture. Normally, that many people don't finger point at me this much in my personal life!

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

Struggling With Business Rule Discovery - Jump In Use Case Design

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

Data Dictionary: Lean Is A Reasonable Objective

How much time is wasted in a project by data specific misunderstandings? No one really knows because data misunderstandings and their impact is extremely difficult to track. A data dictionary can certainly help but it is not the same as a bag of magical pixie dust. They take time to create, strategies to get them successfully leveraged by teams (that are unaccustomed to using them) and require maintenance in order to stay relevant. 

A data dictionary is a table that describes data and an analyst can exert quite a bit of freedom in how they are created. The most classic representation is a name, description, composition and associated values. One problem I've seen in data dictionaries in the past is that someone adopted a "fill in the template" approach. In one case, someone duplicated whole data sets, changed the names and then submitted the data dictionary as a completed deliverable. A classic example where the importance of submitting a deliverable was regarded higher than completing a high quality deliverable. 

NAME: Compliance Inspector
DESCRIPTION: One of more individuals that perform compliance inspections, documents the results and escalates violations in the appropriate manner. 
COMPOSITION: Employee ID, Employee Name, Office Location, Phone, Email and Department ID.
VALUES: Mandatory: Employee ID, Employee Name

In this example, we are describing an entity that will be responsible for entering data into the system for a specific record type, such as a compliance audit. One thing about the example might jump out to you, if you are into lean data sets. Aside from the name and description, there doesn't appear to be anything unique about this data element from the entering data standpoint. 

NAME: Compliance Inspector
DESCRIPTION: One of more individuals that perform compliance inspections, documents the results and escalates violations in the appropriate manner. 
COMPOSITION: Employee ID, Employee Name, Certification ID, Certification Renewal Date, Office Location, Phone, Email and Department ID.
VALUES: Mandatory: Employee ID, Employee Name

In the first example, we could have dozens of identified entities but the system wouldn't do anything unique to them. With the addition of the Certificate ID and Certification Renewal Date, we do have very unique elements for this entity. So we could have a General Data Entry entity in the data dictionary that would be used the majority of the time to meet system requirements. All the other similar but unique entities would appear thereafter and support the associated business rules.

© 2016 Dwayne Wright