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
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!