Use Case Design

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

Use Case Size, How Much Is Just Right?

Nice to have a daily view of the Seahawks stadium during the work day!

There is a threshold for determining if a use case is:

- too small (therefore not really needed)
- too small (probably missing something)
- too small (main point should be integrated into another case)
- too large (needs editing)
- too large (needs decomposition)
- or that the size is just right

and often that determination is made strictly based upon step count in the main flow. I've seen some analysts claim that the step count should fall between 10 and 15. Although this isn't a bad place to start, it is not just the amount of steps because other factors might come into play such as ...

- the complexity of the steps
- the number of actor / system interactions
- the audience that will be consuming the information

I'll even take this a bit further because the main flow steps in the use case really shouldn't overshadow the rest of the information in that use case. The steps in the use case often are the "greatest among equals" in regards its components but the entire use case length is the real concern.

I have a golden rule, well it is more of a golden guideline. Overall, the use case should fit on one page in MS Word. In fact, I tend to create a page break for each use case and this isn't by accident. If the use case doesn't mostly fill the page, its value in the package should be challenged. By the same measuring stick, if the use case is more than one page, it should be challenged in regards to decomposition opportunities. 

I’ll admit that this guideline was born out of how I hated seeing a use case span two pages. To me, this was a potential thought breaker and I felt that contiguous thought is a paramount concern in use case communication. I admit, this is a bit goofy but it does seem to work for me. As always, I would love to see your thoughts on the topic.

© 2016 Dwayne Wright