Precondition in an Use Case

Question

I'm creating a Use Case for a project for school and I'm confused about the precondition field. I can understand preconditions like, "must be logged in" or "needs an account."

But what if the software is a local setup? To me, it sounds logical that a precondition is that "the software needs to be installed." But on the other hand, this precondition looks weird because otherwise, you would not have this Use Case in the first place.

So my question, in short, is: Can system requirements or software installation be a part of a precondition?

Answer 1

Really good question that tackles the heart of the UML problems - it's weak semantics. The answer to your question is therefore - could be right, could be wrong. UML sets the notational rules, and defines only basic element semantics (e.g. "A precondition must be fulfilled in order...").

We could even go further with preconditions like "operating system should be correctly configured" or even worse - "computer has electricity"... These discussions can easily turn philosophical. :)

In my experience there is a way to make use cases efficient - build another UML model, a complementary one, which would be used to formulate preconditions, postconditions and even use case scenarios (the same question you made for preconditions can be made for scenarios as well - which is a correct abstraction for a scenario? Or, is "turn on computer?" a valid step in a scenario?).

In order to achive this I normally use conceptual class diagrams - I model my domain and then express pre/post conditions and scenarios in terms of these elements (classes and their attributes) AND ONLY USING THESE ELEMENTS. This make a lot of sense, especially knowing that pre/postconditions query system's state, neatly reflected by objects/values.

Returning to your example, if you wonder about the precondition "the software needs to be installed", you simply ask yourself "Do I really need a class 'Software' with an attribut 'isInstalled'?"

Then you most likely realize that you probably do not need this precondition because it is simply too "low level" and out of my domain's scope. Now you just need to define your domain. :) Here is a simple example of a similar situation, demonstrating the idea (keep in mind that use case and class models are drawn on separate diagrams):

This method not only make it easier specifying use cases, but also make complementary class model which permit domain specification, business rules identification and a first abstraction of the system design.

Good luck and have fun!

Answer 2

Let's keep in mind that use cases are really high level requirements on what your software/systems needs to implement. In this way, the preconditions should only relate to the software (or system) you are building and not to external elements (e.g., "the computer is connected and turned on" is not a good precondition). As you start to realize your use cases as sequence or activity diagrams, for example, the preconditions give you some clue that a check may need to happen in the software, maybe necessitating a call to some other operation/module/class. This realization exercise will help you determine the form that the precondition will take, and even if it is still required depending on the structure of your application.

To take you example, the "have to be logged in" precondition may be necessary if you expect different behaviour if the user is logged in or not, or if different privileges are required for the operation.

So, some system requirements could be preconditions (e.g., connectivity to a device) and some software installation may be a precondition (e.g., a required companion product integration), but only if they have a direct effect on the use case itself. The installation of the software for your app should not be a precondition: the app can't check if it is not installed as it can't run and it it does execute then it is obviously installed...

Answer 3

For me, system requirements and/or software installation can be a part of a precondition but as always it must be relevant in the context of your use case. For example, your system will have a different behavior if a hardware or a third tool is or is not installed.